Plato：面向企业的 ai coding 框架

现在已经有很多 AI coding 框架了。面向绿地项目的 GSD 、Superpowers ，Brownfield-leaning 的 grill-with-docs ，还有真正面向棕地项目的 OpenSpec 。那么，是不是我们已经没有必要再发明新的框架了？

AI 编程的困境

巨型 PR 每天都要面对同事创建的巨型 PR 。问了同事，其实他也不知道这个代码在写什么。最后只好草草地点了 approve 。

假阴性单元测试 项目的代码慢慢地开始变得不可控，大家已经不知道哪些逻辑在哪些文件里面。所以出了 bug 也不知道怎么修复，只能让 AI 来修复。但是 AI 可能会把你大量的代码重写，然后宣称已经修复了这个 bug ，并且单元测试都通过了。但是你发现线上系统的另一个部分坏了。

上下文过大 当你在一个会话中跟 agent 聊了一段时间，它已经知道了很多代码的规范和反模式后，你重新开一个会话，它又忘记了。又或者你已经把这些规范写到了 prompt 上下文中，但是随着时间的推移，它又开始犯同样的错误。

没有针对企业的最佳实践 你想到了用那些有名的框架。你翻遍了网络，发现确实有很多好用的框架可以从无到有生成一个产品。但是你面对的是一个老项目。你不能把它搞坏，否则会有严重的后果。 OpenSpec 看起来可以，但是它更多的是面向个人开发者。随着时间的推移，大量的 Spec 被产生，agent 的上下文越来越不够用。

总结起来，就是这些框架距离真正的程序员的工作太远了。我们来看下一个在企业中工作的程序员的日常。

程序员的日常

一个真正在公司上班的程序员的一天大概是这样的：每天上午有一个 standup meeting 然后从 Jira 上拿到 ticket 开一个新的 branch ，然后开始做这个 ticket ，测试，然后提交，并生成 PR

什么是 Plato

我常常看到在论坛上有人问，现在有什么好的 Best Practice 吗？老实说，我也没找到。但是我根据多年的程序员经验，结合了上下文管理，形成了自己的方法论。于是我决定把这套方法论做成一个开源框架，希望可以帮助到大家。这个框架叫 Plato 。

特性

用于棕地项目： 适用于已经有大量项目上下文，并且拥有庞大代码库的棕地项目
每个任务使用新的会话： 每一个任务都启动一个全新的会话，保证上下文的干净
分角色加载上下文： Plato 将改动的任务分为多个角色，每个角色只加载自己需要的上下文。
用提问和重构审核代码： 提问是 Plato 的行为核心。在设计阶段，agent 会提问你。在代码审核阶段，你需要提问 agent 。让开发者养成通过提问和重构来审核代码的习惯，而不是逐行阅读代码。
面向规则编程： 在任务的开发过程中逐渐地积累规则文档。常见的规则文档有 CLAUDE.md 、AGENTS.md 。但是它们都不适合企业级管理。Plato 在项目内将文档分为了各种角色适用的文档和项目架构文档等。

如何使用 Plato

安装 Plato

npx skills@latest add CodePlato3721/plato -y -g

第一次使用之前，使用 /plato init 来初始化项目。它会在项目下建立这两个文件夹：

.plato: 这是 Plato 运行必须的规则文件
plato-workspace：这是 Plato 和你共同维护的项目文档，是属于这个项目的资产

使用 Plato 的时候，你需要至少打开 2 个终端窗口。一个用来做 guide 会话，一个真正用来执行任务。guide 的作用是使用 /plato 这个 skill 来控制开发流程，它会帮你创建 ticket ，维护任务进度，并给你真正执行任务的 claude code 命令行。如果你用 VS Code ，你可以用 claude code 插件当作 guide 。

举一个例子。你从 Jira 上拿到了一个 ticket number：PRJ-123 。内容是：给系统增加购物车功能。执行的步骤：

在作为 guide 的 claude code 窗口中使用 /plato PRJ-123。然后它会问你这是一个 feature 还是一个 defect 。你选择了 feature 后，它会询问你这是一个 simple feature 还是 complex feature
这是一个跨页面的复杂特性，所以你可以选 complex feature 。然后它会建立 plato-workspace/tickets/PRJ-123
为这个 ticket 建立了工作区域后，它会给你一个执行工作 agent 的命令： claude --dangerously-skip-permissions --session-id "96d8647c-6f2d-4452-afcd-3d6eb725a3e5" --append-system-prompt-file ".plato/designer/..." "ticket-number=PRJ-123..."
你打开第二个终端，然后执行这个命令。如果在 VS Code 中，你可以打开终端窗口执行这个命令
当这个任务完成后，使用 /exit 退出这个工作 agent ，然后再使用 /plato PRJ-123 得到下一个工作 agent 的命令。重复这个过程，你会经历 design 、planning 、coding 这几个阶段，最后完成任务

使用 Plato 开发的过程，就是不断地在 guide 会话中使用 /plato <ticket-number> 来得到工作 agent 的命令，然后使用这个命令单独打开一个终端执行这个任务。任务完成后，通过询问来审核 agent 完成的任务，并不断地为项目的规则文件添砖加瓦。你每次完善后的项目规则文件都会被作为下一次任务的输入被加载进 agent ，形成一个良性的循环。

框架哲学

这个框架的哲学是 透明： 相比起同时启动多个不可见的 subagent ，在 Plato 中永远只有一个 agent 在工作。它不会自动提交代码，而且它会要求你 review 它产生的内容。它也没有酷炫的控制系统，只有纯粹的命令行和代码。 松散： 每一步的成果都是可以人工编辑修改的，整个步骤如果你不满意，可以 reject agent 的工作结果，从而重新开始这个任务。它是在辅助作为专业程序员的你的工作，而不是主导你的工作。 提问： 提问是 Plato 工作的灵魂。在设计阶段，agent 会通过询问你来完成任务；在代码审核阶段，agent 会逼迫你询问它来完成 review 。让程序员养成通过询问来 review 代码的习惯，而不是阅读代码。 规则： 使用 Plato 强调的是，你的成果不是代码，而是你在执行任务过程中不断产生的规则。这些规则会被不断地添加到项目的各个 .md 文件中。这些规则是你和你的项目的真正资产。这些规则可以保证你的 agent 工作得更有效率。

结论

总之，在这个 AI 时代，谁都可以用一句话来让 agent 复刻一个现有的产品。但是写出代码和写出可维护的代码之间，是一座无法轻易逾越的鸿沟。这个鸿沟需要的不是编写代码的能力，而是通过多年项目开发积累下来的方法论和大局观，也可以称之为 “设计感”。通过使用 Plato ，将你的设计感融入到代码中，从而生成可维护的工程代码。

项目主页： https://github.com/CodePlato3721/plato

关于作者

微博：@代码 Plato 主页： https://weibo.com/u/1041257881