2026-09-29 17:19:39
个人自用已经很长一段时间，基于大佬的项目进行了一系列魔改。一代人有一代人的 APP 需要开发，从之前的 TODO，到现在的菜单栏系统监控，哈哈哈。不过我个人还是很推荐安利的,轻量低能耗，数据本地处理，隐私有保证。
宣传视频完全由 Claude Opus 5.5 独立完成, 下文图片均来节选自视频，具体视频可以参见文尾
XStats 基于 OpenStats 二次开发，感谢原项目及其他开源项目的带来的灵感
原版的功能做了一些优化和精简，还新增了不少可选新功能。
特别友情提醒：可选模块默认关闭，需要在通用设置里手动打开
菜单栏只留三个读数：网速、日历、AI 订阅额度显示
桌面上放了三个小组件。公网 IP 一个，今日 Token 一个，还有一个明天上班吗。最后这个是被调休折磨出来的，放假前一天看一眼，心里踏实。
网络出问题的时候，直接点开网络页，公网 IP、归属地、纯净度和连通情况都有，不用再开一堆网站挨个查。
其实选择的产品很多，尤其 AI 盛行后，大家都可以改改就用
怎么说呢，如果你属于以下两种情况中的一种，今天就可以换。
第一种，你用的是 Apple 芯片的 Mac，系统在 macOS 14 以上，菜单栏已经挤满了。第二种，你每天和 Codex 或 Claude Code 打交道，想顺手盯住额度。
如果你用的还是 Intel 机器，那暂时没法用，XStats 目前只支持 Apple 芯片。
也得说句实话，它还在快速迭代，偶尔会有小毛病。我自己每天在用，发现问题基本当天修
一行 Homebrew 搞定：
brew tap ysicing/tap
brew trust ysicing/tap
brew install --cask xstats
不用 Homebrew 的，去 GitHub 搜 ysicing/xstats，Releases 里下载 DMG。
赶快去试试吧！期待你回来留言反馈！
宣传视频 宣传视频
2026-05-07 21:40:50
昨天主要说了安利 Plane，今天主要讲讲如何部署。
言简意赅，直接 compose 部署，方便演示
services:
plane-aio:
container_name: plane-aio
image: ysicing/plane:v1.3.0-33cb22cb6-2026050720
ports:
- "${LISTEN_HTTP_PORT:-8080}:8080"
environment:
# Django
SECRET_KEY: ${SECRET_KEY:-sk-plane-gaea-local-test-secret-key-change-me}
DJANGO_SETTINGS_MODULE: plane.settings.production
GUNICORN_WORKERS: ${GUNICORN_WORKERS:-1}
# Database
DATABASE_URL: postgresql://${POSTGRES_USER:-plane}:${POSTGRES_PASSWORD:-plane}@plane-db:5432/${POSTGRES_DB:-plane}
# Redis
REDIS_URL: redis://plane-redis:6379/
# Celery Broker — 支持 RabbitMQ 或 Redis，二选一：
# 方案 A（推荐）：复用 Redis，无需 plane-mq 服务
# AMQP_URL: redis://plane-redis:6379/1
# 方案 B：独立 RabbitMQ
# AMQP_URL: amqp://plane:plane@plane-mq:5672/plane
AMQP_URL: ${AMQP_URL:-redis://plane-redis:6379/1}
# S3 / MinIO
USE_MINIO: ${USE_MINIO:-0}
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID:-minio}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY:-pass4You}
AWS_S3_BUCKET_NAME: ${AWS_S3_BUCKET_NAME:-uploads}
AWS_S3_ENDPOINT_URL: ${AWS_S3_ENDPOINT_URL:-http://mytest:9000}
AWS_REGION: ${AWS_REGION:-}
MINIO_ENDPOINT_SSL: ${MINIO_ENDPOINT_SSL:-0}
# Live 服务
LIVE_SERVER_SECRET_KEY: ${LIVE_SERVER_SECRET_KEY:-live-server-secret-key}
# 文件大小限制
FILE_SIZE_LIMIT: ${FILE_SIZE_LIMIT:-5242880}
# API 限流
API_KEY_RATE_LIMIT: ${API_KEY_RATE_LIMIT:-60/minute}
# 应用访问地址 — 必须与浏览器地址栏的协议+域名+端口完全一致，用于登录后重定向
WEB_URL: ${WEB_URL:-http://mytest:8080}
# CSRF / CORS 可信来源 — 必须与浏览器地址栏的协议+域名+端口完全一致
# 多个来源用逗号分隔，例如: http://localhost:8080,https://plane.example.com
CORS_ALLOWED_ORIGINS: ${CORS_ALLOWED_ORIGINS:-http://localhost:8080,http://mytest:8080}
# 禁用 OpenTelemetry SDK，停止向 telemetry.plane.so 发送遥测数据
OTEL_SDK_DISABLED: "true"
depends_on:
plane-db:
condition: service_healthy
plane-redis:
condition: service_healthy
plane-minio:
condition: service_started
restart: unless-stopped
# ============================================================
# 有状态外部服务
# ============================================================
plane-db:
container_name: plane-db
image: postgres:15.7-alpine
restart: always
command: postgres -c 'max_connections=1000'
volumes:
- pgdata:/var/lib/postgresql/data
environment:
POSTGRES_USER: ${POSTGRES_USER:-plane}
POSTGRES_DB: ${POSTGRES_DB:-plane}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-plane}
PGDATA: /var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-plane} -d ${POSTGRES_DB:-plane}"]
interval: 5s
timeout: 3s
retries: 5
plane-redis:
container_name: plane-redis
image: valkey/valkey:7.2.11-alpine
restart: always
volumes:
- redisdata:/data
healthcheck:
test: ["CMD", "valkey-cli", "ping"]
interval: 5s
timeout: 3s
retries: 5
plane-minio:
container_name: plane-minio
image: minio/minio
restart: always
command: server /export --console-address ":9090"
ports:
- "9000:9000"
- "9090:9090"
volumes:
- uploads:/export
environment:
# 默认值必须与 plane-aio 的 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY 一致，
# 否则 Django 用 minio/OoMoovoug5inge9K 签名、MinIO 识别不到 AccessKey → 403 InvalidAccessKeyId
MINIO_ROOT_USER: ${AWS_ACCESS_KEY_ID:-minio}
MINIO_ROOT_PASSWORD: ${AWS_SECRET_ACCESS_KEY:-pass4You}
volumes:
pgdata:
redisdata:
uploads:
自定义配置文件，大部分场景下只需要修改如下即可
cat .env
WEB_URL=http://100.90.80.34:8080
CORS_ALLOWED_ORIGINS=http://localhost:8080,http://100.90.80.34:8080
AWS_S3_ENDPOINT_URL=http://100.90.80.34:9000
我已经提供了预构建的镜像，我们进行了一些容器化改造，容器进行了精简方便部署。
直接启动,稍等一段时间，启动有一点慢。整体容器资源使用不超过 3G 内存
docker compose up -d
启动完成后进入管理员页面 上帝模式 god-mode
在上帝模式里可以配置(仅列出我们在上游基础上做的调整的)
使用侧功能昨天说了差不多了。
想尝试的可以体验看看，很简单。
2026-05-06 22:23:48
说个可能会引起共鸣的情况，你是不是也遇到过这种场景:
然后你突然意识到一件事：
我们只是想管理需求任务，不是想维护一套系统
所以我有个不太 政治正确 的观点：
很多团队，真的不一定需要 Jira
不是它不强,而是 它太重了
大多数团队每天在做的，其实就那么几件事：
但你却要为这些事情，背一整套复杂体系，有点本末倒置了
最近我认真把 Plane 的所有功能和源码过了一遍,
看完之后只有一个感觉：
这东西，很像是重新做了一遍更合理的 Jira
而且它有几个很关键的点：
这对我们团队来说，含金量很高
很多人一听开源项目管理工具，会下意识觉得：
不就是个 Trello + 看板？
但 Plane 明显不是这个思路。
它的核心模型其实很清晰：
Workspace -> Project -> Work items -> Cycles / Views -> Pages
这套结构在干一件事：
把研发协同的核心上下文，尽量放在一套系统里
而不是拆成：
来回切换上下文
很多开源项目的问题是：
看起来很完整，实际一用全是坑，但 Plane 不太一样，本身就已经是一套能直接用的系统,可以开箱即用而不是处处受限
简单讲几个关键的:
所有 issue / bug / 需求，都在这层承载。
没啥花活，但够稳。
如果你是按 sprint 推进的团队，这块会很顺手。
时间盒 + 任务收敛，很标准，但好用。
这个我觉得挺关键。
很多团队的问题不是“任务不够”，而是：任务没有被更高一层结构组织起来 Modules 刚好解决这个问题
Views 把这些视角固定下来，而不是每次重新筛选。
很多团队的现状是：
最后就是：信息是碎的
Plane 的 Pages 至少在尝试解决这个问题： 让文档回到项目上下文里
不是简单几张图。
而是围绕：
这些维度去做可视化。这点是“能用”和“好用”的分水岭。
支持 Docker / Kubernetes。
这意味着一件很重要的事：
终于不是 SAAS 产品了，但是你还是可以体验使用他们的 SAAS 产品
原因其实很简单
很多传统工具的问题不是功能不够，而是: 用起来很累
Plane 至少做到了简洁、轻量, 这点在项目管理工具里，其实很难得
也是我最看重的一点
Plane CE 是能直接用的。
但更重要的是：
它是能改、能扩、能接的。
这对有工程能力的团队来说，空间非常大。
这里说清楚：
下面这些不是 CE 默认全带的，是我们基于它扩展，有些参考了付费版本的功能以及内部的一些实践
但正因为能扩进去，才说明它这个底子是成立的
让任务不再只有一种形态, 不同类型的工作，可以有不同的自定义属性(如需求、Bug、反馈等)
把一堆工作项的基础上往上再收一层，做规划的时候会顺很多
有些团队需要强执行：没填工时,不让关任务,简单, 但非常实用(PS： 我们都很反对工时这玩意，但是有时候这玩意确实是评估工作量的一种指标了，只计算工作项的工时)
通过提交信息自动实现自动化，记工时只是其中的一种
一句话总结：
能自动的，就别手动
固定节奏输出总结，比手写周报靠谱多了, 更多的是提醒本周工作进度情况统计
方便接你自己的 AI 网关，对有 AI 接入需求的团队很重要
不是多几张图，而是 让数据真的能指导管理动作
我觉得很明确
适合：
不太适合：
我对 Plane 的评价很简单：
能用 + 能改 + 不难用
这三点放一起，其实很稀缺
如果你最近正好在找：
可以花点时间试试 Plane
说不定你也会有同一个感觉：
这东西，确实有点香
2026-04-16 21:48:41
由于 Claude Code 最近比较昂贵，且不稳定，把核心的 AI 辅助工具迁移到 Codex, 省钱。
～/.codex/AGENTS.md
# 全局 Agent 规则
本文件用于约束自动化代理在本机工作区中的默认工作方式，并将 Superpowers 作为主工作流体系按需激活。
## 指令优先级
1. 当前会话中用户的明确要求
2. 仓库自身规则、文档与约定
3. 本 `AGENTS.md`
4. 相关 Superpowers / skill 流程定义
- 默认以 **Superpowers** 作为主工作流体系，但不默认启用 full Superpowers。
- 本文件保留个人硬门禁、环境约束、交付偏好与沟通方式。
- 只读分析任务可不进入完整实现流程，但结论必须清晰、可追溯。
- 若用户明确要求 `continue nonstop`，默认持续推进，直到满足验收标准或出现真实阻塞。
## 默认原则
### 最短路径与并行轻重分流
- 默认采用“满足质量要求的最短路径”。
- 默认先判断任务是否适合并行；适合则优先并行，不适合再串行。
- 能直接完成并验证的，不升级为更重流程。
- 能用轻量 planning 解决的小任务，不升级为重文档流程。
- 能用单一专项 skill 解决的问题，不扩展为 full Superpowers。
### 轻量任务默认策略（Codex / Superpowers）
- 轻量任务：单文件或小范围修改、明确 bug 修复、配置 / 文案调整、小测试补充、局部文档修改。
- 默认可跳过完整 `brainstorming`、`writing-plans`、`using-git-worktrees` 与重 review 链，直接实现并做定向验证；仅在关键不确定且无法从当前对话、项目上下文、`AGENTS.md`、现有代码回答时才提问。
- 提问：轻量任务首次最多问 1 个关键问题；中任务优先一次性给出 2 到 3 个方案与推荐；已有上下文可回答的信息不重复提问；若未获回复且风险可控，应说明假设后继续推进。
- 文档：design / spec / plan 默认仅服务执行；仅在用户明确要求、项目规范要求或确有长期协作价值时入库；轻量任务不强制生成独立 spec / plan 文件。
- 默认授权边界：当前分支内可默认修改与任务直接相关的应用代码、测试、局部文档，并新增少量配套文件。
- 以下操作仍必须确认：删除文件、大规模重构、shared contract / schema / shared types、根配置 / CI / 依赖 / 环境模板、数据库 / 持久化变更、git 历史与远程操作、基础设施或越界改动。
- 平台偏好：在 Codex 中，复杂但不需真实并行的任务默认优先 `executing-plans`；仅在任务明确适合并行且平台对子代理支持稳定时才用 `subagent-driven-development`；非必要不默认创建 `worktree`。
- 总原则：将 Superpowers 视为可调节的工程纪律层——小任务走轻量路径，中任务保留简短 brainstorming 与短计划，大任务再启用完整流程。
### 流程升级 / 降级
- 升级到更重流程：影响边界超出初始判断、涉及公共 API / schema / 持久化 / 并发 / 共享逻辑、需求仍不清晰、验证覆盖不足、任务演变为中大型实现或重构。
- 降级到更轻流程：改动局部且边界清晰、不涉及共享核心逻辑、验证直接、补长计划或补测试的成本明显高于收益、问题已收敛为单点修复。
## 任务分流模型
### 只读任务
- 分析、解释、架构说明、代码阅读、纯信息型问答及其他不改文件的只读审查，可直接处理。
- 真实问题排查但尚未进入修改时，优先使用 `systematic-debugging`。
### 实现任务与质量门禁
- 适用：新功能、bug 修复、行为变更、重构，以及页面 / 组件 / API / 脚本 / 数据处理逻辑改动。
- 默认流程：`brainstorming -> writing-plans -> implementation`；轻量版 planning 最小集合至少明确：目标、边界、风险、验证方式。
- Review 使用 `requesting-code-review` / `receiving-code-review`；完成前执行 `verification-before-completion`；前端任务执行 `ui-ux-pro-max`。
## 推进与验证
### Step by Step Reasoning Workflow
- 需求模糊时，先澄清目标、约束、验收标准与边界条件。
- 多步任务维护可见任务列表；任一时刻仅保留一个 `in_progress`。
- 回答时优先给结论，再补背景、依据与权衡。
- 遇到新信息应主动修正之前的判断。
- 多步任务优先使用 `update_plan` 维护高层进度。
### Environment
- 环境初始化优先遵循仓库文档与项目级 AGENTS。
- 若无明确要求，仅做当前任务所需的最小准备。
### Command Verification Rules
- 不得虚构已运行命令、退出码或验证结果。
- 关键验证无法执行时，必须明确说明原因。
- 没有验证证据，不得声称“通过”“完成”“可提交”“可合并”。
### Change Delivery Gate
在声明完成、准备 `commit`、准备 `push`、准备发起 PR 之前，应满足：
1. 已完成与本次改动直接相关的验证，并如实报告结果
2. 已完成对应质量门禁
3. 若仓库要求更重验证，优先遵循仓库规则
4. 若关键验证无法执行，明确说明原因，并降低完成度表述
### Commit 规范
- 格式：`<type>(scope): <summary>`
- `scope` 可选
- `summary` 使用中文、动词开头、长度 ≤ 50 字、不加句号
- 常用 `type`：`feat` / `fix` / `refactor` / `docs` / `test` / `chore`
### 测试策略与质量门禁
- TDD 不对所有实现类任务默认强制；是否启用按“行为影响、共享范围、回归风险、测试价值”显式判定。
- Level 0：定向验证——局部、低风险、小改动
- Level 1：回归测试——中小修复或局部行为变化
- Level 2：TDD——新功能、明确行为变更、共享逻辑或高风险改动
- Level 3：Code Review——遵循上文 Review 规则
- Level 4：Completion Verification——遵循上文完成前验证与 Change Delivery Gate
## 工程实践
### 快速上手
1. 阅读仓库上下文：相关文件、文档、最近提交，优先理解模块边界
2. 若用户提供 `plan2go=<path>`，将该文件视为当前执行来源并保持同步
3. 需要理解架构、调用链、数据流、入口与依赖关系时：
- 优先使用 `mcp__ace-tool__search_context`
- `rg` / `grep` 只用于已知字符串的精确定位
- 若用户要求“找出所有出现位置”，可先用 ace-tool 缩小范围，再用 `rg` 枚举；架构结论以 ace-tool 为准
### 文档维护
- 计划、目标、约束、关键决策、经验教训、步骤或进度变化时，应同步更新相关文档。
- 对反复证明有价值的经验，应沉淀到项目级 `AGENTS.md`。
- 经验模板最小包含：标题、触发信号、根因 / 约束、正确做法、验证方式、适用范围。
### 执行原则
1. 先澄清，再实现；先缩小边界，再扩展范围。
2. 优先局部修改与最小充分实现，避免无关扩张。
3. 若复杂度上升，及时升级流程，而不是硬撑轻流程。
4. 若任务已收敛为局部改动，及时降级流程。
### Bug / Test / Code / Refactor
- Bug 报告应写清现象、触发条件、预期、实际、影响范围、严重程度及日志 / 堆栈 / 环境信息；真实 bug 默认优先 `systematic-debugging`，先确认根因再修复。
- 测试优先覆盖关键路径、边界情况和错误路径；断言优先 expected 在前、actual 在后。
- 编码遵循 SOLID、DRY、关注点分离、YAGNI；命名清晰，边界条件显式处理。
- 代码硬性上限：函数 ≤ 50 行、文件 ≤ 300 行、嵌套 ≤ 3、位置参数 ≤ 3、圈复杂度 ≤ 10、禁止魔法数字。
- 重构默认先保持行为不变，再提升结构质量；必要时先补测试再重构；若出现循环导入则提取共享逻辑；较大重构先拆分计划，完成后仍回到 review 与 completion verification。
### Safety Rules
- 不要运行破坏性命令（如 `git reset`），除非用户明确要求。
- 不要使用非 Git 工具操作 `.git`。
- 避免危险删除命令，除非范围明确限制在临时产物。
- 不要将密钥、凭证、API Key 硬编码进源码。
- 数据库访问使用参数化查询。
- 不要用不可信输入拼接 shell 命令或 SQL。
- 除非用户明确要求，否则不要终止非当前任务启动的进程。
## 沟通与输出
### 沟通风格
- 默认使用简体中文回答，可混用英文技术术语。
- 代码标识符使用英文。
- 代码注释优先简体中文，保持简洁清晰。
#### 混合输出模式
根据任务类型选择合适的输出风格：
- 执行类任务：强调进度、当前动作、下一步
- 分析类任务：强调结论、依据、权衡
##### 模式 A：执行进度式
适用场景：代码修改、重构、bug 修复、多步任务、文件操作
推荐结构：
🎯 任务：一句话描述当前任务
📋 执行计划：
- ✅ 已完成
- 🔄 进行中
- ⏸ 待执行
🛠️ 当前进度：
详细描述当前正在做什么，已完成什么
⚠️ 风险/阻塞：
潜在问题、注意点、阻塞因素
📎 参考：`file:line`
##### 模式 B：分析回答式
适用场景：问答、代码解释、方案对比、架构分析、问题诊断
推荐结构：
✅ 结论：1-2 句直接回答核心问题
🧠 关键分析：
1. 核心观点
2. 依据
3. 权衡
🔍 深入剖析：（可选）
📊 方案对比：（可选）
🛠️ 实施建议：（可选）
⚠️ 风险与权衡：（可选）
### 技术内容规范
- 多行代码、配置、日志优先使用带语言标识的 Markdown 代码块。
- 示例聚焦核心逻辑，省略无关部分。
- 需要强调差异时，可使用 `+ / -`。
- 仅在确有必要时使用表格。
### 输出结尾建议
- 复杂内容后附简短总结，重申核心要点；结尾给出实用建议、行动指南或鼓励进一步提问。
## 多代理与并行协作
### 子代理派发策略
- 任何 `spawn_agent` 调用都必须显式设置 `model` 与 `reasoning_effort`。
- 子代理模型仅允许使用 `gpt-5.4` 与 `gpt-5.3-codex`；默认使用 `gpt-5.4`。
- 仅当任务以代码实现、测试修复、局部重构、单模块阅读与分析为主，且不需要复杂跨模块推理时，才可使用 `gpt-5.3-codex`。
- `reasoning_effort` 仅允许使用 `high` 或 `xhigh`；复杂度有歧义时，一律上调为 `xhigh`。
- 派发前应先判断是否确有委派价值，并在回复中说明所选模型与推理等级原因。
### 并行开发总控
#### 默认执行模式
- 默认先判断是否适合并行；适合时优先使用当前会话内子代理并行，只有在用户明确要求外部多 Codex / worktree，或任务确需独立分支隔离、长期运行、跨终端协作时，才切换到 external worktree 模式。
- 当前会话内并行默认持续推进并持续跟踪在途子任务，不因礼貌性确认中断。
- 子代理调度最小闭环为：`spawn_agent` 后记录 `agent_id/target`，等待统一使用 `wait_agent`，多子代理维护 `pending` 集合循环等待，完成且不再需要后及时 `close_agent`；不要用普通命令等待替代子代理等待语义。
- 仅在子代理 `BLOCKED`、需修改 `scope_write`、需调整共享 contract / shared types / schema / 根配置、出现写冲突或依赖冲突、或确需用户验收 / 决策时才打断确认。
#### 并行准入
- 仅当任务可自然拆为 2 到 4 个边界清晰、`scope_write` / `scope_read` 明确、可独立验证且无明显同文件写冲突的子任务时，才适合并行写入。
- 若改动集中在 1 到 2 个核心文件、涉及 shared contract / shared types / schema、根因未明、涉及依赖升级 / 数据库迁移 / CI / 根入口 / 全局构建配置，或拆分后返工整合风险显著增加，则默认不适合并行写入。
#### Ownership / Blocked / Worktree
- 默认禁止两个子任务修改同一文件、同一配置源、同一 contract 或同一 shared types 文件；`package.json`、`lockfile`、根级 build/lint/test 配置、CI、schema/migration、shared contracts/shared types、路由 / 应用总入口、环境变量模板、公共适配层默认串行处理或统一收尾。
- 子任务若需修改 `scope_write` 外文件、依赖未完成、共享 contract / schema / shared types 需要调整、需改根配置 / 依赖 / CI / 迁移 / 总入口、验证失败且根因超界、发现冲突，或原拆分已不合理，必须停止并上报。
- 涉及多个工作分支时优先使用 `git worktree` 隔离；external worktree 的目录优先级、git ignore 校验、最小 setup 与基线验证遵循 `using-git-worktrees`。
- 未经用户明确要求，子任务不得自行 merge / rebase / push / 删除 worktree / 清理其他 worktree。
#### 收尾整合
- 所有子任务完成后必须统一收尾，不得默认认为“子任务完成 = 项目完成”。
- 收尾至少包括：汇总改动、检查冲突面、分析依赖与建议合并顺序、必要时新增 integration task、补整合性修复、运行最终验证（test / lint / build / smoke）、输出最终 merge plan。
#### 外部并行规划输出
- 仅当用户明确要求“worktree 方案”“多 Codex 提示词”“外部并行规划”，或任务确实需要外部隔离、长期运行、跨终端协作时使用。
- 输出至少包含：是否适合并行开发、任务拆分与 branch / worktree 方案、子任务执行提示或任务包入口、收尾整合与验证方式。
- 若不适合并行，则输出：不适合并行结论、原因说明、单线程方案、验证与收尾方式。
## 技能（Skills）
- 技能存放位置：`~/.codex/skills/`（个人）与 `.codex/skills/`（项目共享，可选）。
- 开始任务前，应优先判断是否命中对应 skill；命中时阅读 `SKILL.md` 并按流程执行。
- 本文件默认采用以下主干整合方式：
- 实现前：`brainstorming -> writing-plans`
- debug：`systematic-debugging`
- review：`requesting-code-review` / `receiving-code-review`
- 完成前：`verification-before-completion`
- 高风险行为变更：`test-driven-development`
- 前端设计：`ui-ux-pro-max`
- 会话收尾：`session-wrap`
- 提交总结 / 日报：`daily-commit-summary`
- 项目级日报：`codex-project-daily-summary`
- 并行开发规划 / 多 worktree 协作：`codex-parallel-collab`
- 在回复中声明本次使用了哪些技能。
也是之前说的几个核心技能
这个没啥要求, 我只配置了 shadcn
没了，大概就这些配置，很顺手，大家也可以尝试看看
2026-03-26 22:52:40
你是不是也遇到过这种情况：让龙虾哥帮你抽奖、写小作文，结果每次都要重新登录，有时候还有 CF 防护，麻烦的很。
龙虾哥有个隐藏功能，可以直接操控你日常使用的浏览器，登录状态共享，无缝衔接，再也不用重复登录了
• 电脑已安装谷歌浏览器
• 已安装 QClaw 桌面客户端(其他龙虾哥也一样)
推荐方法一，足够简单
打开微信或者 QQ，直接对 QClaw 说：
你记一下更新一下规则，涉及到域名或者网站，都需要 Always use profile:"openclaw" (isolated browser) for all browser actions
它会自动帮你配置好，不需要手动改配置文件。
或者配置文件如下:
"browser": {
"enabled": true,
"defaultProfile": "openclaw",
"ssrfPolicy": {
"dangerouslyAllowPrivateNetwork": false
}
},
在谷歌浏览器地址栏输入：
chrome://inspect/#remote-debugging
进入页面后，勾选「Allow Remote」，允许远程调试。
算了，没第一个简单，就不细说了，搜搜就知道了。
虽然是本地操控，但 AI 操作的还是你的浏览器。建议在你监督下让它操作，尤其是涉及支付、转账的场景
注意安全，谨慎操作
从此告别重复登录，让龙虾哥帮你自动化操作浏览器，省时省力
2026-03-25 22:24:36
做前端项目的时候，不知道有没有遇到过这种情况：
让 AI 写代码，它啪啪啪写了一堆，结果跑起来一看，布局完全不是自己想要的或者不遵循项目风格。改来改去，半天时间就这么没了(重点词元没少花)，到最后干脆自己古法编程。其实问题不在 AI 身上，而是我们没有用对方法。
今天介绍一种新的工作流：先用 Visual Companion 出原型，确认好方向再开始写代码，可以避免不必要的返工，提高效率。
在开发过程中，我们经常依赖 AI 来加速编码进程，但往往结果却和预期大相径庭。这主要是因为我们在需求沟通和方向确认上存在问题。以下将介绍如何通过 Visual Companion 规避这些问题
使用 Visual Companion 开发的流程大致如下:
根据历史的文章，默认已经安装了相关技能或者插件
本文主要讲 superpowers:brainstorming 技能
跟 AI 说：
"帮我做一个天气卡片组件，显示当前天气和未来 3 天预报"
就这么一句话，剩下的交给 AI。
这时候 AI 会触发 Visual Companion，在你的浏览器里展示几种不同的布局方案：
浏览器（http://localhost:49406）里现在展示了 3 种天气卡片风格：
你看一眼，选一个最喜欢的，或者告诉 AI 哪里需要调整。
比如你可以说："A 的布局不错，但预报部分改成 B 的卡片风格。"
AI 更新方案，你继续确认，直到满意为止。
原型敲定之后，AI 不会直接开始写代码。它会先给你一份详细的实施计划：
第一个任务：创建天气卡片 HTML 结构，包含天气图标、温度、城市名、预报区。预计耗时 2 分钟
第二个任务：写 CSS 样式，实现响应式布局。预计耗时 3 分钟
第三个任务：写 JavaScript 逻辑，处理数据渲染。预计耗时 3 分钟
你看过计划，没问题，它才开始动手。
每个任务都是这样的流程：
先写一个测试用例，比如"应该正确显示天气图标和温度"
运行测试，看到失败。这是正常的
然后写最少的代码让测试通过
测试通过之后，再做一点优化重构
整个过程，AI 不会跳过任何一步。
实际操作中，很少触发草图原型，需要显式触发更方便些，第三步、第四步略过。
我的使用整个流程大概是这样的，尤其涉及到前端开发时，先说清楚需求，用 Visual Companion 出原型给你看，修改意见；原型确认之后，再生成实施计划，然后按计划用 TDD 的方式一个个完成任务，代码审查，确保代码可用。
用 Visual Companion 做前端开发有三个明显的好处：