一款针对Claude Code使用中的种种不便而设计的编程智能体，在开发者与编写代码的智能体之间加入了一个负责审查的智能体。审查智能体可以推动任务依次经过规划、实现和检查，而无需在每次响应后等待人工给出新的提示词。会话由服务器保存，工作也在服务器上运行，因此任务要继续进行，并不需要本地终端始终保持正常。一次功能开发的实际运行展示了这套工作流的运作方式，也显示出哪些环节仍离不开人的判断。
从语音请求到编程任务
工作流的起点是看板，即让卡片按阶段流转的任务面板。它的列固定为backlog、plan、in progress、blocked和done。这种有限的结构是有意为之：系统没有让开发者自行配置大量自定义状态和自动化规则，而是为编程智能体提供了一条可预期的任务路径。
在一次运行中，一条语音请求创建了26号卡片，内容是在/resume会话列表中用彩色圆点显示Git状态。红色表示尚未推送，黄色表示尚未合并，绿色表示已合并。语音助手不只是把请求转写成文字，还创建了一张包含用户故事、需求和测试标准的卡片，并将其打开供人查看。启用auto plan和auto build后，把卡片移到规划列，便开始了代码检查和计划起草。这两个开关决定卡片进入下一阶段时，是否自动开始规划和构建。
▲ 语音创建的任务与会话状态
同样的语音控制还可以打开看板、浏览过去的工作。在另一次查找中，请求调出16小时前关于ASCII图标的讨论后，系统找到了对应的会话及其终端上下文。这是语音在听写之外的一个具体用途，但并不能说明在所有会话中检索都同样可靠。
审查循环与服务器如何配合
在这套系统试图改进的逐轮工作流中，开发者需要阅读智能体的响应、加以评估，再写出下一条提示词。而在这里，开发者先定义任务需求。随后，审查智能体检查编程智能体的进展，可以否决不符合需求的计划，并持续推动工作，直到满足完成条件。存在歧义的权衡仍可交还给开发者，而不是由智能体私下定夺。
命令行界面（CLI）提供终端操作，但会话和聊天记录保存在中央服务器上。这种设计使得在一台终端上启动的任务，可以在另一台机器上或通过Telegram继续进行。/resume视图会列出各个会话及其Git状态，开发者可以用Tab键在并行的会话之间切换。
每个编程会话都运行在各自的Docker容器中（一种带有独立工具和依赖项的隔离环境），并使用单独的Git分支（一条并行的代码变更线）。文件读取、编辑和命令执行都在服务器端的工作空间中进行，而不是直接作用于开发者本地的工作树。统一运行环境，旨在减少不同客户端设备之间可用工具的差异。这也让不同任务能够同时推进，而不会出现多个智能体同时修改同一批本地文件的情况。
一次终端崩溃检验了这种分离
在处理PHA-26号卡片期间，基于React的终端界面因“Maximum update depth exceeded”错误而崩溃。CLI确实存在缺陷，但编程任务仍在服务器上继续运行。重新打开界面后，又能访问正在进行的会话。
▲ 终端崩溃后仍在继续的编程任务
这一事件对该架构构成了一次范围有限但有价值的检验：这次界面崩溃没有中断这项后台任务。它并不能说明所有服务器故障或中断都不会造成影响，但确实说明了，为什么在日常开发中，将长时间运行的编程进程与终端视图分离可能很重要。
随后，这项功能任务运行了337项测试，其中334项通过，3项失败；这3项失败被认定为原有的基线失败。这一结果比简单地说运行成功或失败更有参考价值：所请求的变更已进入验证阶段，但报告的测试并未全部通过。
代码写完之后
完成的卡片被移向完成状态后，自动Git同步流程随即接手。系统拉取上游变更，合并任务分支并推送结果。GitHub上的提交5cca2fa显示，状态指示功能的变更涉及5个文件。之后的/resume视图展示了带有合并状态和彩色圆点的会话历史，这项功能也在它本要改进的工作流中得以呈现。
集成流程在设计上会考虑智能体工作期间上游发生的变更。如果无法解决冲突，它会把任务标记为blocked，交由人工处理，而不是将合并视为已完成。这次功能开发展示的是一次顺利完成的同步，并不代表并行分支之间的冲突总能自动解决。
审查智能体和编程智能体这两个智能体还共享六条决策原则。它们被要求在修改前先检查现有代码，在自行构建前先寻找成熟的做法，为增加的复杂度说明理由，用测试验证假设，不超出所请求的范围，并考虑最终用户的体验。这些原则有时会相互牵制。例如，更简单的实现可能无法实现所要求的界面行为；按照设计，这类悬而未决的选择会交给开发者处理。
这套工作流的启示
这里展示得最清楚的改进是连续性：一项任务从语音请求出发，依次经过卡片、计划、代码检查和Git提交，途中还挺过了一次本地终端崩溃。代价是必须遵循既定的看板和工作流，而无法进行大量自定义。测试失败、可能出现的合并冲突以及人工审批的需要，也依然是流程的一部分。
如果要搭建类似的编程工作流，首先应为每项任务定义需求和测试标准。将长时间运行的执行过程与终端界面分离，隔离并行分支，并在接受已完成的任务之前检查测试结果和合并状态。在持续推进有帮助的地方使用自动规划和构建，但要为人工解决歧义或受阻的集成保留清晰的路径。