用 AI 写代码这件事，过去一年变化太大了。

去年这时候大家还在琢磨「怎么让 Claude 别乱改代码」，今年已经变成「怎么让 10 个 AI 会话别在同一个项目里打架」。

但说实话，大多数人现在写 AI 代码的方式，跟一年前没太大区别——还是打开终端丢一句话，改改改，满意了下一段。

这套流程对个人项目够用。但当项目变复杂、需要多人协作、或者隔了两周再回来改的时候，问题就出来了。

我观察到的现象是：AI 编码这件事，正在经历三次进化。

第一阶段：对话流

最原始的形态。你打开终端，跟 AI 说「帮我写个登录页面」，它写完，你看看，不满意再改。这个阶段的核心特点是：所有上下文都在对话历史里。

它的好处就是快。非常快。没有仪式感，没有流程负担。我很多个人项目就是这么写的。

但它的局限也很明显：

每次新开一个会话，AI 就失忆了。上回聊了三个小时定下来的架构设计、API 约定、组件拆分方式，新会话里全得重来。你要么找聊天记录复制粘贴，要么让 AI 读代码自己猜。

更要命的是，当项目代码到了一定规模，AI 开始频繁犯一些低级错误。比如在项目明明用 pnpm 的情况下，它给你写 npm 的命令。在项目用 Zustand 管理状态的情况下，它给你写了 Redux 的代码。

不是说它蠢。是你没说清楚，它只能从训练数据里猜一个最常见的做法来填。

对话流的本质是靠 chat 同步上下文。写得越快，就越容易在同一个地方反复绕圈。

这个阶段适合：一次性脚本、原型、个人玩具项目。

第二阶段：规则流

到了第二阶段，大家开始意识到光靠对话不行。于是诞生了各种约束手段。

最基础的是 .cursorrules、CLAUDE.md、AGENTS.md 这类文件。把项目规范写进去，告诉 AI 用什么包管理工具、目录结构长啥样、测试怎么写、不做哪些事。文件是持久化的，写一次就持续生效。

再进一步是 skill。把流程固化成可复用的工作流。比如需求澄清 skill、debug skill、review skill、发布前检查 skill。模型不够强的时候，这些 skill 很有用——它们告诉 AI 做事的方法论。

然后就有了像 grill-me 这样的东西。你让 AI 做个什么，它不急着写代码，先一个问题一个问题地审你。把需求里的模糊地带全部挖干净了才动工。一开始被这么问挺烦的，但用了几次之后我承认——被问烦了之后写出来的东西靠谱很多。

还有更重的方案，比如 Superpowers。它会强制走完整的流程：需求澄清、计划、实现、review。每一步都有规范，不能跳过。

到这个阶段，AI 写代码的质量明显稳定了。低级错误少了，代码风格也统一了。

但这个阶段有个问题绕不开：平台锁定。

你在 Claude Code 里配的 skill、rules、hook，换到 Cursor 就废了。如果你用 Codex，又要重新来一套。团队里有人用 Cursor，有人用 Claude Code，规矩统一不了。

而且随着项目增长，rules 文件会越来越长。新规范加进去，旧规范不敢删，最后变得臃肿不堪。AI 会话上下文一满，这些约束文件就优先被挤出去了——你能做的就是祈祷 AI 在开头读了一下。

还有一个更深的问题：规则归规则，任务归任务。

rules 文件告诉 AI 项目有哪些长期规范，但它不告诉 AI 当前这个任务做到哪一步了、接下来该做什么。这些信息还是在对话里靠 chat 传递，本质上没有脱离第一阶段。

这个阶段适合：认真在做的中型项目、个人或小团队。

第三阶段：工程流

第三阶段做的事情很简单：把原来在 chat 里靠说的话才能同步的信息，变成项目里本来就有的一份文件。

这个思想最早是从一些内部实践里长出来的。Anthropic 发过一篇文章讲他们内部怎么让 AI 记住项目规范——把上下文写进文档，每次会话启动时让 AI 读。想法很直接，但在真实项目里用起来有一堆坑要填。

于是就有了几个更完整的开源方案。

Trellis

Trellis 在这方面是目前我觉得最完整的一个尝试。它是一个项目级框架，不绑定 IDE 或具体工具。

它的核心目录是 .trellis/，里面装几样东西：

• spec/ — 项目规范，按模块拆成小文件，不是一个大胖子
• tasks/ — 任务目录，每个任务有 prd.md、设计文档、上下文清单
• workspace/ — 每个人的工作日志，按开发者隔离
• workflow.md — 定义整个开发流程的阶段划分

它做了几件事把上面说的那些问题挨个堵上：

跨会话记忆。每次会话启动，AI 先读 .trellis/ 里的内容——当前活跃任务、上次的 journal、项目规范索引。不用人再复述一遍。

跨平台共享。.trellis/ 这套核心是一套，不管你在 Claude Code 还是 Cursor 还是 Codex。每个平台需要 trellis init --claude 单独初始化一次适配层，但核心规范、任务记录是同一套文件，进 git 的。

上下文按需加载。AI 动手写代码之前，先去读当前任务相关的 spec 文件，不是把整个项目规范一股脑塞进去。做前端的时候读前端的 spec，改后端的时候读后端的。

任务闭环。spec 管长期规范，task 管当前任务，workflow 管阶段推进，journal 管工作记忆。任务收尾时，AI 会判断哪些经验值沉淀回 spec。下次开新会话，这些经验就在那里。

还有一些细节设计我觉得挺有意思的。比如 workflow-state breadcrumb——每次你给 AI 发消息，它会注入一段简短的状态提示，告诉 AI 当前在哪个阶段、下一步该做什么。AI 不用猜「我做完了吗」，它知道当前在 planning 还是 in_progress 还是该 finish 了。

再比如 trellis-brainstorm，它把 grill-me 那种一次一个问题审需求的模式直接做到了工作流里。你提需求，它不会直接开写，先追问，把所有模糊地带填平了再开始。

Trellis 支持 17 个平台，从 Claude Code、Cursor、Codex 到 Gemini CLI、Pi Agent、Copilot 都有。

但老实说，它的门槛不低。.trellis/ 目录层级挺多，初次见到会有点懵。task 管理对小型改动来说偏重——有时候就修一个 bug，也要走 create → plan → implement → check → archive。另外这框架还在快速迭代中，changelog 隔几天就一大串，有些功能是 0.6.x 才加进来的。

其他方案

还有几个方向也值得提。

OpenSpec 走的是 spec-first 路线——先写规范再写代码。优势是规范质量高，适合长期维护的复杂系统。但它在任务追踪和跨会话记忆这方面不像 Trellis 那么重。

Cline / Roo Code 这类工具也有自己的 memory bank 机制，做法是把项目知识写进文件，每次会话启动读取。但它们更多是工具自带的功能，不像 Trellis 那样可以跨工具复用同一套配置。

还有一些 团队内部搭建的方案。我在 GitHub 上看到有人分享自己写的 mcp-agent、multi-agent 工作流，用 MCP server 做上下文管理。自由度最高，但维护成本也最高，适合有精力的团队。

怎么选

这三个阶段不是替代关系，是适用范围不同。

对话流最快，适合一个人写小东西。规则流在项目变大时兜底，投入产出比最高。工程流适合规模更大的项目、多人协作、或者团队里用不同 AI 工具的人。

Trellis 是目前我觉得工程流里最有代表性的尝试，但它不是完美的。前期的学习成本和维护投入是真实存在的。

如果你现在的场景是「用 AI 写个人项目，挺顺的」，那没必要上第三阶段。但如果你正在被「每次新开会话全忘了」「换个工具规矩全废了」「项目代码越来越屎山」这些问题困扰，可以考虑试试往上走一层。

反正我自己试了一圈之后的感受是：AI 写代码这件事正在从「怎么让 AI 听我的话」变成「怎么让我的项目告诉 AI 该怎么做」。后者要靠谱得多。