最近我开始做一个新项目，叫 argus-claw。
我准备把它写成一个系列。因为这个项目后面大概率会分出好几条线：有些内容适合写成技术拆解，有些适合写成阶段记录，还有一些更像是方法上的复盘。项目还很早，我反而觉得现在动笔正合适。很多真正决定项目气质的东西，往往就发生在最开始的这几步里。
到我写这篇文章的时候，argus-claw 还没有跑出第一条完整的 review 闭环。仓库里已经有路线图、有阶段文档、有实验目录，也有第一阶段的接线说明，但它还没有长成一个“已经证明自己”的系统。这个状态很真实，所以我想先把真实的起点写下来。
如果直接看目录，其实会更有感觉：
1 | . |
你会发现，现在的它连“半成品代码仓库”都还谈不上，更像是一套刚刚被压实的执行基线。也正因为这样，我更想先把这个阶段写下来。
我一开始想做的，到底是什么
argus-claw 的方向其实并不复杂。我想做一个面向 self-hosted GitLab 的 AI code review 系统，先把最小闭环跑通，再一点点加深它对 Go 微服务场景的理解。后面是否要接 MCP、要不要做 RAG、是否要引入更强的上下文能力，这些都可以继续讨论。但这些都应该排在“先让它真的工作”之后。
我现在越来越警惕一种很容易上头的项目启动方式：脑子里同时出现太多正确的词，结果每个词都想立刻做。GitLab、PR-Agent、Go reviewer、MCP、RAG、多 Agent，这些方向单拎出来都很有吸引力。问题在于，项目第一周承受不了这么多展开。你会觉得自己在快速推进，实际感受常常只是复杂度在快速上涨。
所以 argus-claw 的第一步，被我压成了一句很朴素的话：
1 | GitLab Merge Request -> PR-Agent -> LLM -> Merge Request 评论 |
第一阶段只看这件事能不能跑通。只要这条链路还没通，别的内容都先往后放。
这次我最依赖 AI 的地方，是帮我收束
我这次和 AI 的协作，重点不在“让它多写一点代码”。代码当然也会写，但真正帮我省下大量时间的地方，是它可以很快帮我收束信息。
我手里原本有一份调研文档，也有一些更早的白皮书式想法。它们有价值，但也会互相打架。只要这些材料同时摆在面前，项目就很容易陷入一种反复摇摆的状态。今天觉得应该先自己写 Go webhook 服务，明天又觉得先 fork 一个成熟项目更稳，后天看到 RAG 和多 Agent，又开始想把未来三个月的复杂度一起搬进来。
我把这些材料丢给 AI，不是为了让它替我做决定。我更像是在拿它做一台高频运转的整理机：让它先读完整体上下文，再逼它回答一个更具体的问题，今天到底该从哪里开始。
这个过程中，AI 很快帮我把一个关键判断收紧了：第一阶段别碰 RAG，别碰 LangGraph，别急着写自己的 Go reviewer 服务，也别急着证明一大堆“以后可能有价值”的系统能力。先拿现成的强基座把第一条 review 跑通，再决定后面哪里值得自己下场。
这个判断最后当然是我自己拍板的，但 AI 确实把“收束”这件事做得很快。它能把一份很长的调研文档压出执行边界，也能把互相冲突的材料放在一起对照，让我更容易看清楚哪些内容会干扰当下推进。
我先让 AI 帮我把路修出来
于是，argus-claw 当前最扎实的进展，落在了文档和执行基线上。
我先把项目宪章、路线图、Wave 文档和 Wave 1 的说明立起来，再把已经失去优先级的材料归档掉。这样的动作看起来并不华丽，甚至会让人觉得“你怎么还没开始写核心代码”。可我现在越来越相信，很多项目真正拖慢进度的地方，恰好就是前面没有把规则说清楚。
一旦边界不清楚，后面的每一步都在重新理解项目。写两天代码，停下来想想方向；过两天看到一个新概念，又开始怀疑当前路线；再过几天回头看旧文档，发现自己当时根本没有把“第一阶段成功”定义清楚。真正消耗人的，很多时候是这种反复回退和重复判断，编码量反而显得没那么重。
所以我宁愿先把这些东西钉住。
现在仓库里已经有一个很明确的执行秩序：constitution.md 负责决策准则，roadmap.md 负责多阶段方向，waves.md 负责当前执行，notes/wave-1.md 负责把第一阶段的动作写具体。原来的材料没有消失，只是退出了当前决策链路。这样我每次回来继续推进时，脑子里不会重新打架。
写到这里，我自己也会想到前面那篇《「下一步」，不是一个动作》。当时我写过 knowledge-hub 那种项目更适合走一套压得很细的执行链路，从 /idea、/spec、/plan、/task 一路收束到 /execute。那套方法我现在依然很认同，它很适合方向已经收紧、需求边界已经稳定的阶段。尤其是那种开放接口能力开发、要去对接底层接口、再往上提供能力的项目，你一旦把规格想清楚，后面的推进会非常顺，安全感也很强。
但 argus-claw 现在还不在那个阶段。
我现在手里有方向，有研究，有我自己很强的兴趣，也有几个已经很明确的技术锚点，可我还没有走到“可以认真写规格”的时候。这个项目当前最需要被拍板的东西，还是路线、阶段边界和验证顺序。这个时候如果硬把它塞进一套很完整的 SDD 流程里，文档表面上会显得很正式，心里其实知道很多内容还只是阶段性的猜测。那种稳定感是假的，后面一改方向，前面的规格就会一起松掉。
所以这次我选了一个更适合当前阶段的推进方式：先用 roadmap 管远一点的路径，再用 waves 管眼前这一段。这个套路我以前也用过，在那类开放接口开发的项目里，它对我一直很有效。因为它允许我先把长期方向挂起来，再把当前阶段压得很窄。这样推进的时候，人会很稳。你知道自己暂时不碰什么，也知道这一波只验证什么。项目会沿着一个很安全的节奏往前走，不容易被中途冒出来的新想法带偏。
这大概就是我现在理解的 vibe coding
我对 vibe coding 的理解，这段时间也在变化。
早一点的时候，我会更在意“AI 能不能尽快把东西写出来”。现在我更在意另一件事：AI 能不能帮我更低摩擦地试一条路径，然后再更低摩擦地把错误路径砍掉。
如果只是想到什么就让它写什么，速度确实很快，项目也会很快长出一堆东西。问题在于，那些东西里面混着多少幻觉、多少时机不对的复杂度、多少因为兴奋而提前引入的系统层设计，只有走远一点才会看出来。那时再回头收拾，代价往往更大。
而且我也知道，现在更流行的玩法，往往比我激进得多。开多个窗口，并行丢给多个 Agent，让它们各自推进，再开 subagent，把一部分工作继续拆下去；或者直接上像 openclaw 这种更强调代理协作的工具，让整条执行链路自己往前滚。这种方式我并不陌生，对某些任务也确实合适。边界清楚、验收标准明确的时候，它的效率会非常高。
再往前走一步，其实还有更重的一层想象。比如把需求流转、任务编排、协作沟通、交付追踪这些东西，更多地接到像 Linear、Slack 这样的系统里，让 AI 更深地参与整个研发生命周期。这个方向我并不排斥，我甚至觉得它很值得认真做。真有企业愿意投入时间，把流程、权限、协作方式一起重构，我会觉得那是一件很好的事。
只是这条路的风险也很高。它碰到的早就不只是编码效率，还会碰到组织习惯、责任边界、信息噪声、错误放大这些更难收拾的问题。所以它当然可以做，也值得做，只是需要时间，任重而道远。
从这个角度看，argus-claw 对我来说也不只是一个 code review 项目。它更像是一次很具体的前哨实践：我想先在一个足够窄、又足够真实的环节里，验证 AI 到底该怎么进入研发现场，怎样才能真正带来增益，而不是只留下热闹。
所以 argus-claw 现在我不想一上来就把自己抽离出去。原因也很简单：一旦我把太多动作直接外包给 Agent，我自己能得到的东西就会变少。我会失去一部分贴着问题往前想的过程，也会更少去反复确认那些决定项目方向的细节。我现在更在意的，并不只是把项目推快一点，我还想保留自己在里面思考、怀疑、收束和修正的空间。对我来说，这个阶段的 argus-claw 还值得我慢一点跟着走，而不是站到后面只做分发和验收。
我现在更喜欢把 AI 放在两个位置上。
第一个位置，是研究收束。让它读材料、做对照、帮我提炼第一阶段的边界。
第二个位置，是工程执行。比如把执行文档落下来，把目录骨架搭出来，把 Wave 1 需要的基础物料先准备好，让我能直接从一个更稳定的起点继续往前走。
至于那些真正决定项目方向的判断，还是得我自己负责。举个很具体的例子：argus-claw 现在先走 GitLab + PR-Agent 的闭环，后面再谈 Go 定制 skill、MCP 和 RAG。这个顺序本身就是判断。AI 可以帮我加速，也能帮我把判断写清楚，但它不替我承担取舍。
为什么第一篇我想先写“方法”
如果我等到第一条 MR 评论真正回写成功，再来写 argus-claw 的第一篇，文章会自然滑向结果汇报。那样当然也能写，但我反而会错过现在这个阶段最值得记录的部分。
因为现在最有意思的东西，恰好就是“我怎么开始”。
我怎么面对一堆彼此都很有道理的方向，又怎么把它们压回一个能执行的起点；我怎么借助 AI 去收束研究、剪掉干扰、固定阶段边界；我怎么提醒自己别在项目第一周就把未来几个月的复杂度一起请进来。这些东西写下来，后面再回头看，我会更容易知道哪些判断经得住时间，哪些判断只是当时的情绪。
所以我想把这个系列的第一篇停在这里。它还没有讲到多成熟的系统，也没有展示什么漂亮的功能截图。它只是把一个项目真正开始成形的那个瞬间记下来。
至于这个系列后面会先写什么，我其实也不想定得太死。也许是 Wave 1 里某个具体动作，也许是中途冒出来的一次判断，也许只是我在推进 argus-claw 时突然想明白的一个问题。对我来说，写博客一直都更像是思考、整理和分享。什么时候有值得说的东西，我就写一篇。