自从 AI 大模型出来以后，很多事情，尤其是执行层面的事情，都可以交给 AI 搞定。对做项目的程序员来说，大部分工作和难点，也就集中到了产品设计和任务分配上。
原先程序员是执行者，现在像是升职成了“领导”。但当领导，也没有那么好当。
头脑风暴，会议记录
前期我会先和 AI 聊天，把自己对某个产品的想法一点点聊出来，让 AI 帮我逐渐细化。在 superpowers 工作流里，这个步骤叫 Brain Storm，也就是头脑风暴。
聊完初步想法以后，我会让 AI 帮我做一些调研，再把调研结果保存到单独的 reference 文件夹里。
接着根据聊天内容和调研内容，让 AI 帮我生成 PRD，也就是对一个产品的粗略功能描述。
头脑风暴的过程，可以直接在 Agent 工具里聊，也可以直接用常规的聊天工具。实际上我更推荐后者。
在 ChatGPT 里创建项目以后，每次聊同一个产品，都会在这个项目里进行。每次新起一个话题时，它都可以读到整个项目里的其他历史聊天记录，这样我就不需要每次重复介绍这个项目的背景。
这有点像每次我跟它开会，它都会把会议内容记录下来，下次就不需要我重复说上次的内容了。
由于头脑风暴的过程中，思维往往比较跳跃、混乱，而且可能会反复纠结、修改设计，如果想每一次聊天都把结论及时整理成文档，会比较花精力。所以，AI 如果能直接读取所有历史聊天记录作为上下文，我觉得是更好的选择。
还有一个原因，这些聊天软件可以免费使用，也能节省一点 Token 成本。ChatGPT 也可以结合 VSCode 或 Cursor 读写单个文件，详见下面截图示例。
项目细化，需求评审
有了 PRD 以后，我开始细化文档。一般我会写这样几类文档。
PRD：描述 Why / What，也就是为什么做、做什么。
Spec：描述 How it works，也就是系统如何工作，主要是更详细的功能细节描述。
Plan：描述 How to build，也就是如何落地实现。比如用什么技术框架、有哪些数据库表、API 接口等等。
Prototype：也就是原型图。让 AI 用 HTML 生成产品原型图，对每个功能模块做大概的示意展示。主要作用是帮我自己理清思路，更直观地做产品细节决策。
下图展示了我的一个实际项目的文档结构。我没有直接用目前比较火的 superpowers + openspec 来做，而是借鉴它们的思路，自己从头探索、踩坑，做一套自己的文档管理模式。
虽然这样可能会走一些弯路，但我觉得会让我对 AI 如何写代码有更深的理解。
和 AI 员工一对一聊天
在整个项目开发过程中，最费时间的就是写 Spec 和 Plan。
前期经常要反复修改设计、补细节，里面也会有很多一开始考虑不到的问题。再加上设计一改，其他文件没有同步修改，就容易互相冲突，所以这些文档在初期往往会很乱。
一开始的工作流程是，我和 AI 聊天，让它帮我找问题。找到问题以后，我再告诉它怎么改，它再去修改。改完以后再继续找问题，就这样一直循环。
聊了一段时间以后，我感觉效率很低。而且它每次都还能继续找出新问题，像是永远没有尽头。再加上经常因为沟通不畅改错，还得让它重新改。
这个工作模式显然不对。虽然是 AI 在帮我找问题，也是 AI 在帮我修改，可我还是得一直盯着它、一直回答它的问题。作为老板，我完全没有被解放出来。
员工给我做汇报，我来批阅
探索了一段时间以后，我换了个思路。
我会先让 AI 找出一批 Open Issue，保存到 Open Issue 文件里，列成表格，再给出建议修复方式。
然后我会人工去看这个表格。如果我觉得它给的修复建议合理，就直接不管。如果我觉得建议有问题，就手动改这个单元格。很多时候，AI 会给出两种解决方法，我就删掉其中一种，只保留我觉得更合适的那一种。
等我把整个表格都过完一遍，就会新开一个会话，让它按照表格里的内容修复所有 Open Issue。等它修完以后，我再去看一下 Git Diff，确认它的修改基本符合我的预期。
如此不断循环。
每当 AI 去找 Open Issue 或者修复问题的时候，我没什么事可干，刚好可以去看看电视。
老板没有精力一直盯着员工干活，所以我的工作模式也变了。我让 AI 员工自己去干，隔一段时间再跟它一起开个会。开会之前，它要先把所有问题都总结起来，一次性汇报给我，我再一次性批阅，交给它继续干。
发现员工在偷懒
但这样干了一段时间以后，我还是觉得效率不高。因为每次我让 AI 去找问题，它都能找出几个问题，但不会一次性把所有能找到的问题都告诉我，我还是得经常和它“开会”，讨论每个问题到底要怎么改。
从这里就能看出来，AI 是个比较偷懒的员工。如果你只是让它找问题，它可能默认找 5 个问题就结束了。下次你再让它继续找，它又再找 5 个，然后又结束，不能一直往下找。
后来我试了个办法。我说你一次性给我找至少 20 个问题出来，结果 AI 真的就刚好给我找了 20 个问题。修完这 20 个问题以后，我又说，这次你直接给我找 100 个问题出来，它也真的找出来了 100 个。
关键是，我这个文档里确实有很多细节没有考虑清楚，这 100 个问题也确实存在，并不是它瞎编的。
给员工制定 KPI
但前面这样还是会无穷无尽。我怎么知道文档里到底还有多少问题，怎么尽可能让它一次性把问题找全呢？
和 AI 讨论之后，我有了更清晰的方向。
先明确找问题的目标是什么。我的目标其实很简单，就是先把第一版跑通，不去管太细的细节。
我决定把这个目标直接写进一个 skill 里，让它每次自动调用 skill 去找 Open Issue。这样它就会明确知道，我的目标是尽可能快地实现核心功能。
当上大老板
制定完 KPI 以后，我需要让 AI 朝着这个 KPI 努力。
但前面说了，这个 AI 很偷懒。用通俗的话说，就像驴子推石磨一样，推一圈，转一圈。
于是我借鉴了网上提到的思路，可以通过循环调用 AI，让它反复做同一件事，直到全部做完为止。实际上这个思路也有现成项目，比如 Ralph。
https://github.com/snarktank/ralph
考虑到我的项目场景和别人的不太一样，所以我还是为自己的项目量身定制了一个 skill，而不是直接套别人的东西。
我让 AI 自己创建子 Agent，再让子 Agent 去找问题，找完以后汇报给主 Agent。如果某个子 Agent 这一轮还能找出新问题，就继续循环，让它再找一遍。如果某一轮已经找不出新问题了，就停止流程。
最后我给这个流程设计了三种工作模式。
1、普通模式：直接找问题，写入 OPEN_ISSUE 文档。
2、并行模式：开多个子 Agent 同时找问题。比较适合初期问题很多的时候，可以让多个子 Agent 在不同文件里分别找问题，最后再由主 Agent 把所有问题合并到一起，提高效率。
3、全量模式：循环找问题，直到找不到为止。适合后期文档已经相对完善的时候，让它反复循环，直到找不出问题为止。
还有一个细节，就是允许子 Agent 长时间运行。一开始没有这个细节，我发现主 Agent 等了一会之后，就会认为子 Agent 耗时超出预期，直接把它终止掉。
我实际这么跑了一下，发现确实很管用。还有个很有意思的细节，它运行了一段时间以后，发现子 Agent 还没返回，也没及时更新文档，于是主动给子 Agent 发了一条催办消息，让它尽快。
这让我感觉自己这次是真的当上了大老板，不仅手底下有员工，还有员工帮我鞭打更底层的“牛马”干活。
最后它跑了两轮检查以后，就没有发现新问题了。这说明文档已经相对完善了，这时候我就需要去批阅一下，再让它帮我修复。
修复以后，还可以让它再做下一轮查找，因为修复过程本身也可能动到一些设计，有可能引入新的问题。
这样循环下去，直到最后已经没有太多问题要修复了，就说明文档真的进入了可以落地实现的阶段。
功能实现，拆分任务
文档搞定之后，就是代码实现。
整个项目的完整实现是比较复杂的，最基层的人类程序员很难独立实现一个完整项目，甚至也很难独立实现一个足够复杂的功能模块。
而作为老板，一个很重要的事情，就是把一个复杂任务拆分成很多小块，每一块分批交给同一个员工完成，或者分别交给不同的员工完成，给他们设定每个小任务的目标。
AI 员工和人类员工很类似。
- AI 员工容易偷懒。如果你直接把所有文档全丢给它去实现，它可能会实现出很多缺失。
- 每一个 Agent 只做一个相对小的 Task，它的上下文比较简单，这样反而更容易可靠地完成任务，Token 消耗也会少。
- 多个 AI 员工一起同时推进，效率会更高。当然，Token 消耗也会集中在这段时间。
所以要把项目拆分成不同的功能模块，并且提前确定好每一个功能模块的文件边界。简单说，就是放在哪些文件夹里。
每一个模块对应一个 Task，把 Task 的拆分结果写到文档里。
扩大团队，分工协作
为了避免多个 Agent 同时开发、写文件导致冲突，一个最直接的思路就是确定每一个 Agent 要写哪些文件，把它们尽量按文件夹分割开来。
另一个思路是利用 Git Worktree，让它们同时在不同的 Git 分支做开发，最后按顺序提交。但即使这样做，也应该尽量避免多个 Agent 大量修改同一个文件，避免冲突。
思路还是和前面写文档类似，让一个主 Agent 负责任务的拆分、分发、进度监督，让其他 Agent 负责实施。
当然，如果你喜欢折腾，还可以用更复杂的 Agent 层级。例如一级主管 Agent 负责整个项目的调度，二级中层管理 Agent 负责每个功能模块，底下的牛马 Agent 负责代码实现。
但由于 Codex 只能一个主 Agent 和多个子 Agent，不能有更深的 Agent 层级了，我觉得也没有必要去折腾。
及时反馈（Harness）
人类员工在工作过程中，领导需要经常跟他们沟通交流，和他们一起回顾近期工作做得怎么样，让员工得到及时反馈，从而调整自己的工作。
而 Harness 编程思想，和这一点很类似。它最核心的思想，就是要给 AI 的工作建立反馈机制，也就是让 AI 自己知道自己有没有做完、有没有做对任务。
具体实现上，就是通过测试，让 AI 知道自己做得对不对。如果不对，就自己尝试修复，修复完了再运行测试，直到成功为止。
对于纯逻辑或者后端这种项目，AI 直接调接口就知道返回结果对不对。
对于有 UI 界面的项目，无论是移动端、桌面端还是网页端，不同的平台都有自己的接口，可以让 AI 操作界面，还可以通过自主截图并分析图像内容，判断界面有没有正常工作。
工作验收
理想情况下，应该是一次性把文档全写好，然后代码一次性生成出来，一切都很完美。
但现实情况是，你不可能真的把文档写得无懈可击。等实现出来以后，又会发现设计上可能有各种考虑不全、细节不具体，或者 AI 并没有完美按照你的设想执行。
我目前有个项目，花了整整两周时间细化和完善文档。
第一版代码实现确实比较快，只花了几天时间，但还不能做到 AI 一次性全部完成。这几天里，我还是需要自己去看代码，再让 AI 修改完善。但总的来说，这已经效率很高了。
版本迭代
第一版只是用最简单的方式粗略实现了我的设想，整个系统的框架都有了，并且能初步运行。
后面我又开始了新一版的迭代。
这一版迭代里，我开始用上了 Codex 的 Goal 功能。下一篇文章我会介绍具体的使用方式和经验心得。
你不干，有的是 AI 愿意干
最后我让 AI 帮我生成了这样一张图，当作文章封面图。我本来想用“鞭打牛马”这种黑色幽默做隐喻，但有些 AI 拒绝生成这张图，说它涉及暴力。
不过没关系，你不干，有的是 AI 愿意干。我换了一个 AI，一下就给我生成出来了。
如果觉得文章有帮助，欢迎分享转发，也欢迎关注我的公众号“搬砖的小明”，及时获取更新
