个人 AI 助理如何参与开发工作

所属项目： 个人 AI 助理

AI 开始参与开发后，最直观的变化是：很多事推进得比以前快。

它能读现有代码、查文档、写第一版实现，也能顺着报错排查。问题是，速度上来之后，过程也更容易散。上午让 AI 改了一个功能，下午又补了两个边界条件，过几天想回头看，很可能只记得“这个应该做过”，却说不清为什么这样改、有没有验证、现在还适不适用。

我后来给 AI 协作开发加了一条很朴素的规则：每个值得持续推进的需求，都要有一份能被人重新接手的档案。

从一句话需求开始，但不能停在一句话

我的开发需求往往很短：加个功能、修一个问题、把一段流程自动化。

收到之后，先在 workspace 根目录建一个目录：

REQS/
└── 2026-08-06-short-slug/
    └── README.md

目录名同时也是这次工作的 req_id。它会绑定到当前协作会话，后续的提交、过程记录和统计可以靠这个标识串起来。

README 不是另一份长篇文档。我固定只写六件事：

1. 需求分类：这是临时脚本、已有项目改动，还是可能长成 Skill 的东西？
2. 需求背景：谁提出、为什么做、最后希望看到什么。
3. 设计方案：准备改哪里，有哪些取舍，怎么验证。
4. 执行记录：只记关键节点，不记流水账。
5. 交付产物：代码、命令、链接、commit 在哪里。
6. 复盘总结：这次有哪些做法值得下次复用。

例如“加一个接口”并不天然等于项目需求。有些一次性数据处理，用完就可以归档；有些改动应该进入项目源码；有些做了几次，才值得沉淀为一个 Skill。先分类，后面文件放哪儿、要不要维护，都会清楚很多。

AI 不负责猜需求，也不替代验收

我会让 AI 先做一件很具体的事：读相关代码和文档，找出已经存在的能力、影响范围和不确定点。

如果需求很明确，小改动可以直接做；如果是新模块或会影响多个地方，先把方案和任务拆开。拆分不是为了看起来专业，而是让每一步都有一个可验证的结果。

一条任务最好能写成这样：

- [ ] 增加接口参数校验
  - 验收：类型检查通过；传入非法参数时返回预期错误；原有调用不受影响

而不是“把参数校验加上”。后者听起来完成了，实际上无法判断完成得对不对。

AI 很擅长提出方案、补遗漏、写实现；人要保留的，是需求的边界和验收标准。尤其是“要不要做”“先做哪一种”“这个结果算不算过”，不能因为 AI 给出一个顺畅的答案就自动跳过。

提交不求多，但要卡在能回看的节点

我不要求每改一行就 commit。那会把历史切得太碎，也会增加无意义的打断。

比较合适的节点通常是：

• 需求骨架和设计已经确定；
• 一个功能可以编译、运行或被预览；
• 测试、构建或线上核验通过，形成可交付版本。

提交之后，把 commit 记回 REQ。这样下次遇到类似问题，不用先翻对话，也不用从 Git 历史里猜哪个提交有关。

验证也一样。AI 说“改好了”只是一个待验证的说法。代码改动至少要选一个与风险匹配的检查：单测、类型检查、构建、命令实际运行，或者部署后的最小核验。

我踩过的一个坑是：本地构建通过后，直接说预览已更新，实际上还没有部署到线上。后来给自己补了一条：凡是说“线上已经更新”，必须从公开链接再看一遍。

这条规则听起来笨，但它把“我以为”换成了“我确认过”。

这套流程对 AI 有什么用

它不是为了约束 AI，而是为了让下一次协作不必从头猜。

需求档案给了 AI 可读的上下文；阶段提交让修改有稳定锚点；验证结果告诉它什么已经成立、什么还只是设想；复盘则把一次性的排查，变成下一次可直接使用的经验。

现在我不会把 AI 当成一个只负责输出代码的聊天窗口。更像是把它放进一个可以协作的开发流程里：它负责扩大我的检索、实现和排查能力；我负责目标、边界、判断与最后的确认。

如果有人想照着试，最小版本不需要复杂工具：先给一个需求建一页 README，把“为什么做、改了什么、怎么验证”写下来就够了。后面的 req_id、自动统计、Skill，都是在真的需要以后再补。

还在路上，先记下来。