上一篇《在熵增的世界里，造一个叫「元」的熵减装置》，讲的是我为什么要造它。
那篇稍微有点仰望星空。这篇我们低下头，看看工位。
因为理想虽然是熵减，现实往往是：AI 个个聪明绝顶，凑在一起却像一群刚入职、没拉群、没看文档，还不好意思承认自己不知道该干什么的实习生。
于是这篇只谈三个实际问题：它解决了什么，为什么长成现在这个样子。最后，你怎么用十分钟先试一条工作流。
太长不读
Pi Felix 是我基于 pi-coding-agent 做的一套个人 AI 工作系统。
说人话：我给一群 AI 补了间办公室。
有前台接活，有人干活，有人查岗，有人验收，还有一本不太厚、但至少记得昨天发生过什么的工作手册。这样换会话、换 Agent，甚至换机器以后，工作不至于当场失忆。
如果你也在反复解释背景、寻找 AI 产物，或者经常遇到“程序运行成功，事情却没做完”，可以先复制文末的模板。选一条每周重复的工作，连续跑两次。
Pi Felix 的价值不在第一次。AI 第一次把活干漂亮，大家都见过。
第二次它还认得路，才算真本事。
我为什么不再满足于“AI 已完成”
有一次，自动任务照常返回成功。
心跳正常，退出码是 0，满屏都是令人安心的绿色。堪称电子世界的岁月静好。
唯一的问题是：我真正要用的那份报告，已经几天没有更新。
程序确实运行过，工作却没有完成。
这很像一个人每天准时打卡，工位也热，咖啡也喝了，到了周五你问他交付在哪里，他温柔地看着你。
我后来把检查规则改成了：
退出码正常
+ 当日产物存在
+ 更新时间合理
+ 必要内容可读取
= 任务健康如果进程正常、产物却缺失，状态只能是 degraded，不能继续用一张绿脸糊弄我。
另一次，工作在一台电脑上已经做完，另一台电脑上的 Agent 却看不到记录。它认真检查了一圈，然后郑重宣布：这项工作没有推进。
语气很专业。结论完全错了。
我本来有点生气，后来想想又不能全怪它。Agent 只能根据自己看见的证据判断；而我过去的协作方式，基本靠心灵感应。
于是我把跨机协作从“默认大家都知道”，改成显式交接。任务由谁发出、谁接收、产物在哪里、谁确认、当前是什么状态，都要落在可读取的记录里。没有同步证据，就只能说“我这里暂时看不到”，不能把看不见当成没发生。
这两次失败让我意识到：
一次回答完成了，不等于一项工作形成了闭环。
生成速度已经足够快。真正拖慢我的，是回答之后的搬运、确认、寻找和返工。
或者更坦白一点：以前我以为自己在指挥 AI，后来发现自己的主要工作是给它们当人肉剪贴板。
我要求 Agent 留下五样东西
Pi Felix 不会凭空保证每项任务都有完美交付。谁这么保证，建议先检查一下他的演示视频有没有剪辑。
它做的事情朴素得多：把交付协议写清楚。执行 Agent 完成任务后，不能挥一挥衣袖，只留一句“已完成”，而要尽量留下五样东西。
- 正式产物：现在可以直接使用什么；
- 产物位置：以后去哪里找到它；
- 验收状态：是否满足完成条件，有什么证据；
- 交接记录：谁做过，下一步由谁接；
- 反馈沉淀：这次纠错，下次如何避免重犯。
第一项解决眼前的问题，后四项防止三天后的我对着文件夹发呆。
它把一次回答接进下一次工作，而非止步于多生成一份内容。
这也是我现在判断 AI 工作流是否有效的标准：
第一次做得惊艳不算难。第二次开始时，不需要重新解释，才是真正的效率。
一间很小的 AI 办公室
我最初希望“元”什么都亲自做。
它知道全局，又能调用工具，看起来像一位不会累的超级员工。我把能塞的事情都塞给它，心里还有一点“终于实现一人公司”的小得意。
然后它连续读取大量文件、修改模块、处理执行细节，原本用于保存目标和状态的上下文也被挤满了。
它做好了局部工作，却逐渐失去全局视野。一个本来应该当老板的 Agent，被我用成了勤奋但茫然的高级打杂。
后来我把责任拆成了一间小办公室里最基本的四类。
一个 AI 可以兼任多个角色，但入口、执行、运行监督和质量验收四种责任不能混在一起。
人决定目标、优先级和红线。
调度官只做四件事：读、判断、分派、记录。它不吞下重执行任务，尽量保留全局视野。
执行者一次完成一件边界明确的事，不顺手扩大范围。
守护者和审阅者分别看两种不同的问题：
- 运行监督：今天有没有跑，产物是否存在，状态是否健康；
- 质量监督：结果有没有偏离目标，系统是否在制造重复劳动。
这当然不是为了模仿公司。一个人已经够辛苦了，没必要再给自己虚构八个部门、十二张审批表和一次 AI 团建。
它只是把过去全压在我脑子里的责任显式拆开。最小版本甚至只需要一个 AI，在不同步骤切换角色。
最快的用法：先跑通一条工作线
你不需要先部署 Pi Felix，也不用一开始就配置多 Agent、跨机同步和长期记忆。
我理解那种冲动：刚看到一个系统，就想把所有机器拉进来，顺手建个知识库，再给每个 Agent 起一个像《三体》人物的名字。忍一下。
先选一条每周至少重复一次、现在仍然需要手工拼接的工作。比如周报、会议材料、行业跟踪或内容发布。
建立这样一个最小目录：
my-workflow/
├── WORKFLOW.md
├── inputs/
│ └── weekly-notes.md
├── outputs/
└── trace.md在 WORKFLOW.md 里写：
task: 根据 inputs/weekly-notes.md 生成本周项目复盘
context:
- 上周复盘
- 本周会议与任务记录
allowed_writes:
- outputs/
- trace.md
done_when:
- outputs/weekly-review.md 已生成
- 包含已完成、未完成、风险、下周动作
- 每个判断都能追溯到输入材料
handoff_to: 我来验收，并把反馈追加到 trace.md然后把这段话交给你正在使用的 AI：
请按 WORKFLOW.md 执行。
完成后不要只回复“已完成”，请交付：
1. 可直接使用的正式产物；
2. 产物路径；
3. 对照 done_when 的逐项验收；
4. 下一次接手必须知道的状态和问题。
不要修改 allowed_writes 之外的内容。第一次运行通常不会很优雅。你主要在修入口、完成条件和交付位置，也可能顺便发现自己根本没想清楚“做好”是什么意思。
第二次只更新 inputs/weekly-notes.md，不要再完整解释背景。让 AI 读取上次的 WORKFLOW.md 和 trace.md 继续。
如果第二次仍要大段说明，上下文就没有沉淀好。结果找不到，说明产物位置没有固定。你仍然无法判断它是否完成，则是 done_when 不够具体。
我把这套内容整理成了可以直接复制的第一条 AI 工作流模板。
四个设计取舍
这套系统里有很多技术细节，但我认为真正重要的是四个取舍。
1. 默认文件，而不是先上数据库
任务、状态、记忆和交接记录优先使用普通文件。
文件容易阅读、搜索、版本控制，也方便人直接修正。数据库当然更强，也更有一种“我正在建设基础设施”的快乐。
但在个人系统早期，看得见通常比吞吐量更重要。毕竟我的工作还没多到需要纳斯达克级别的撮合引擎。
2. 默认追加，而不是覆盖历史
日志和跨机记录尽量 append-only。
多台机器同时写共享文件时，覆盖式更新很容易产生冲突，也会抹掉判断过程。保留时间线，出错时才知道发生过什么。
3. 默认检查产物，而不是只看进程
程序运行只是动作，用户拿到可用结果才是交付。
所以运行状态与产物状态要分开检查。一个任务可以“进程成功，交付降级”，这种诚实比全绿的仪表盘更有价值。
4. 默认让人保留最终判断
AI 可以读取材料、拆任务、执行和检查，但目标、优先级、公开边界和高风险动作仍由人决定。
我想提高的是人的判断杠杆，而不是把人从系统里删除。
它现在还不是什么
Pi Felix 不是安装以后就能自动经营一切的“AI 公司”。我自己都还没有自动经营好自己，它就更不敢承诺了。
它更像一套可本地化的组织方法和能力包。单机的任务、记忆与验收协议可以直接使用。跨机器交接需要额外部署同步通道，例如独立的 agent-handoff。自动化能否稳定运行，也取决于本机权限、Node 环境和具体服务。
项目里提供的部署指引可以让另一个 AI 助手协助检查环境、安装依赖和本地化配置，但不应该跳过权限确认，更不可能替你定义什么结果才算有价值。
它仍然在迭代。Bug 有，边角也不圆，有时还会非常诚实地把问题重新交还给我。
但这反而是我现在更在意的东西：它能不能让一条真实工作线持续变轻，而不是在演示里完成一次魔法。
如果你也有同样的问题
不要先搭一个庞大的系统。
先复制模板，选一条每周重复的工作，跑两次。
第二次结束后，只问四个问题：
- 我有没有少解释一次背景？
- 产物能不能直接进入下一步？
- 失败时能不能看见断点？
- 上一次的纠错有没有被保留？
只要其中几项开始改善，这条工作流就值得继续打磨。等真实摩擦出现，再增加自动化、多个 Agent 或跨机协同。
技术不是这件事的起点。
起点只是一个很朴素的愿望：我不想每天早上打开一个新对话，再跟一个记忆清零的天才互相自我介绍。
如果 AI 真能帮我们省下时间，我希望省下来的不是思考，而是那些“昨天发生过什么”“文件放在哪里”“你做完了没有”的办公室废话。
至于省下来的时间拿去做什么——认真生活，胡思乱想，或者什么都不做——那是人的事。