afk

AFK

这项技能会利用你离开的时间，让一个项目变得更好。它会收集证据、广泛生成想法，在本地分支上实现其中最有力的几个，并留下一份你两分钟内就能读完的报告。

这里重深度而非速度。你会离开数小时，因此第一批改动完成并验证后，应从列表中选取下一个想法，而不是就此停下。

审查界面时使用 better-interface，审查差异时使用 interface-review，探索某个组件的替代方案时使用 variant，对其进行压力测试时使用 break。

为使用产品的人创造更好的体验

每个想法都要回答一个问题：使用这款产品的人真的会觉得它变得更好了吗？指出这个人是谁，以及这个想法在哪个时刻能帮到他们，例如读者点开失效链接时，或访客寻找某篇文章时。仅仅让代码更整洁或让 Agent 显得很忙的想法，都不符合标准。

根据需求证据为通过标准的想法排序。真实流量访问 404 页面算证据，生产环境中的错误也算。产品文案未兑现的承诺，或此人已在同类项目中推出的修复，也都算证据。没有证据的想法仍然可以实现，但排序时永远靠后，差异也应保持较小。

有时跳出常规

大多数晚上，最有力的想法都是修复和润色。有些晚上，其中一个想法应当出人意料。它可以是产品自身内容催生的功能、浏览内容的新方式，或能改变此人工作方式的工具。只要通过上述标准且差异较小，就可以实现。否则，就把它连同值得一试的理由写进报告。

如果列表里只有稳妥的修复，说明构思环节还没充分展开。

与代码库保持一致

改动应当读起来就像是此人写的。在实现任何内容之前，先找出代码库如何解决最相近的问题，并照着做：

• 复用现有组件、钩子和工具函数。只有在现有基础构件无法满足需求时，才有理由新增。
• 使用现有设计令牌来设置颜色、间距、圆角、字体和动效。从最接近的现有界面取值，不要自行创造。
• 遵循代码库的文件布局、命名和导入风格，以及 Agent 文档中的规则，包括何时编写注释。
• 界面文案应沿用产品现有的语气、长度和标点。
• 保持现有架构。引入新的状态库、样式方案或数据层，只能作为想法写进报告，绝不能在无人看管时实现。

如果同类项目已经解决了相同问题，就移植那套方案，并用本代码库的设计令牌重新调整样式。

保持可撤销

此人回来后应面对选择，而不是收拾残局：

• 从默认分支创建名为 afk/<date> 的新分支。若工作区中有未提交的工作，就使用单独的 git worktree 进行开发，并确保原有工作保持原样。
• 在本地提交，每次提交只包含一项改动，并遵循代码库自己的提交风格。只有在此请求明确要求时，才推送、创建拉取请求、合并、部署、发布或发送消息。
• 将已连接的服务视为只读。可以查看分析数据、错误追踪记录和部署日志，但不得更改设置、数据或集成。
• 保留此人自己的文风。新文案、变更日志条目或帖子应先写进报告，不要直接编辑已发布的内容。
• 只有当同类项目已经用某个依赖完成相同任务时，才添加该依赖，并在报告中注明。
• 对测试运行会写入的任何文件先创建快照，之后从快照恢复。

1. 了解项目

阅读 AGENTS.md 或 CLAUDE.md、README、近期 git 日志、开放的分支和拉取请求，以及关于此人的任何已保存记忆。记下它们要求遵循的约定，例如提交格式、注释规则和组件模式。完成标准：能够说明项目的用途、技术栈，以及评审者会因哪些约定遭到破坏而拒绝改动。

2. 收集证据

阅读所有相关来源。这包括热门页面、404 和引荐来源的网页分析数据、错误跟踪器和运行时日志、CI 结果、未解决的问题和 TODO 注释。还包括产品文案和文档，并对照产品的实际行为进行核查，以及产品最繁忙页面上的控制台。

然后查看这个人的同类项目，看看那里是否已经解决了某个问题，例如搜索对话框、组件或工作流。当每个来源都已阅读，或已说明理由并决定暂不查看时，便算完成。

3. 广泛构思

在做出选择前，至少写出十五个想法。涵盖修复、设计润色、功能、内容、性能、无障碍，以及这个人自己的工具，例如技能或脚本。至少包含三个会改变产品行为，而不只是改变外观的想法。为每个想法写明它帮助的人、相关证据、大致工作量和风险。无法说清能帮助谁的想法，一律删掉。当每个领域都有一个想法，且至少有一个想法会让这个人感到意外时，便算完成。

4. 实现最有力的几个想法

选择证据最充分、且每个都能作为一个小型提交落地的想法。先解决真实的用户痛点，再构建功能，最后进行润色。按照 匹配代码库 中的要求实现每个想法，并在提交前运行项目的检查命令。当每个选中的想法都已提交，或已说明放弃理由时，便算完成。

5. 查看每项改动的实际效果

在用户会接触到每项改动的地方进行测试。界面改动使用浏览器，路由和重定向使用 curl，任何由 AI 支持的功能都使用真实端点。对于视觉改动，要查看浅色和深色主题，以及手机宽度下的显示效果。当每项改动都已确认正常，或标记为尚未验证时，便算完成。

6. 提交报告

最后用一条消息汇报，按以下顺序呈现，让这个人首先看到最重要的信息：

1. 当前情况。 分支、提交数量、任何开发服务器 URL，以及仍在运行的内容。
2. 实现内容。 每项改动各列一条，说明用户现在能看到什么，以及促成这项改动的证据。
3. 验证情况。 区分已确认正常、仅通过类型检查，以及完全未经检查的内容。
4. 由你做出的决定。 代替这个人做出的、他们可能想要撤销的选择。
5. 未实现的想法。 列出其余想法，包括大胆的想法，并分别说明证据和工作量。

保持可逆 中的草稿应和想法一起列出，方便直接粘贴。

完成前检查

模式	修正
提交标题中需要出现“和”	拆成两个提交
某项改动只通过类型检查验证	在运行中的应用里测试，或标记为尚未验证
报告列出提交标题	说明用户现在能看到什么，以及为什么要实现
差异包含这个人尚未提交的文件	将工作移到单独的 worktree，并恢复他们的文件
注释只是在解释代码的作用	删除注释，除非没有它代码会显得不合理
想法列表里只有修复项	回到 3. 广泛构思，补充大胆的想法
某项已实现的想法无法说清能帮助谁	撤销该改动，并将其移入报告
差异中出现了新的颜色、间距值或组件	替换为代码库中最接近的现有选项
还有时间时工作已停止，但仍有想法未实现	实现下一个有证据支持的想法