辅导实录｜一次完整的 AI 编程实践，从原型到前后端

作者：尔东陈在路上｜发布日期：2026-08-27｜原文：https://mp.weixin.qq.com/s/Iii_eXBOf05ZV5n0M2TpDA

昨晚做了第一次一对一辅导，对面是一位有多年开发经验的技术人。聊了快两个小时，临结束他说了一句话：

「很多东西我可能做过，但没有比较贯穿地去落地。」

这几乎是现在大多数 AI 编程使用者的真实状态。工具都摸过：Cursor 用过，Claude Code 装了，SDD 插件也装了。但每次都是零散地用——改个片段、问个报错、生成个小工具。真要端到端交付一个完整项目，链路就断了。他描述过那种感觉：让工具生成一个需求的 spec，跟着跑到一半，「就感觉这个东西废掉了」。

一、原型不是给开发看的文档，是可以复用的资产

我最早探索 AI 编程，切入点不是写代码，是做原型。那时我在公司负责一个研发效能产品，产品和项目管理的活在我手上，技术有研发同学扛。传统做法是用 Axure 或墨刀画原型、写进 PRD、拉开发评审，评审完他们去开发。一个完整点的功能模块，光画原型可能就要两周。

第一阶段我发现，做原型这件事，V0、Lovable 这类线上 SaaS 的效果明显好过在 Claude Code 里直接写提示词。原因不复杂：这类工具在系统提示词里对前端 UI 做了大量强化，你很难自己从零写出一段提示词，把「什么样的 UI 适合企业内部系统」讲清楚。我给它需求，再配几张参考截图，出来的交互和样式都相当能用，对话微调几轮就成型。

但很快撞上第二个问题：风格一致性。产品要持续迭代，每来一个新需求我就新开一个项目生成原型，这次是这个风格，下次又是另一个风格。

解法是把原型从「一次性产出」变成「一个工程」。我起了一个纯前端的原型工程，没有后端，数据全部 mock。好处是 AI 每次生成都能读到工程里已有的组件——表格长什么样、卡片长什么样、菜单长什么样。攒到一定程度，再生成新原型不但风格严丝合缝，速度也快得多，因为一个产品的骨架无非就是那几类组件。

到这里原型本身的问题算是解决了，真正让我觉得「不对劲」的是下一步。

原型给老板过完、需求定了，进入开发阶段，这个原型就退化成一份需求文档——开发同学得重新听我讲一遍需求，再从头用 AI 出技术方案、写代码。那我生成这个原型，难道只是为了把需求讲清楚？开发阶段完全用不上？ 这中间明显有浪费。

刚好团队有个新项目启动，我拿它跑通了完整链路。

原型定稿之后、正式开发之前，我先让 AI 把原型重构一版。生成原型时你根本不会去想数据模型和 API 调用长什么样，所以这一版重构就是把接口契约明确出来——涉及哪些接口、入参出参是什么，让原型按这套契约重写。

有了这个基础，原型就能反推两份技术方案。后端方案的核心其实只有两样东西：接口契约（入参、出参）和数据模型（每个接口读哪些表、基本逻辑是什么）。这两样定清楚，AI 写接口实现基本就是两三轮对话的事。前端方案更简单，原型代码可以直接拿过去用——前提是原型的技术栈必须和实际前端工程一致，否则代码搬不过去，这一环白做。

工程组织上我还做了个小尝试：把原型工程、前端工程、后端工程放进同一个父目录，每个子工程各有自己的 AGENTS.md 或 CLAUDE.md，写清楚「这个是原型、这个是前端、这个是后端」，然后在父目录起一个 Claude Code 会话统一指挥。前端参考原型组件实现，后端按契约和数据模型实现，一个会话里全串起来。

一个细节值得单独说：不要一次性让它把 10 个接口全写完。 学员自己就给出了正确答案——按 feature 走，前后端先通一个，确认符合预期，再做下一个。这个判断是对的，原因有两层：每个 Agent 的上下文有限；模型执行长程任务时容易偷懒，做到一半开始偷工减料，最后给你一个看着完整、实际残缺的交付。

所以拆分任务是用好 AI 最核心的实践。底层逻辑是注意力：上下文用得越多，模型注意力越稀疏，回答越不靠谱。任务拆得越干净，它一次做对的概率越高。

还有一个保证质量的关键动作：在 AGENTS.md 或提示词里明确要求，每写完一个接口，必须配套写好单元测试和接口自动化测试，「测试全部跑通」才算这个任务交付完成。这条写进去之后，后端基本两三轮对话收一个接口。

配套规范我一般在 AGENTS.md 里写三块：架构规范（整体分层、模块划分，比如 DDD 那套怎么落）、编码规范（命名规则，直接把公司或阿里那套塞进去）、技术栈（用什么框架、怎么编译）。

模型选择上有个我反复验证过的差异：前端用 Claude 系列更好，后端逻辑用 Codex（GPT 系列）明显更严谨。 区别在性格——Claude 基本顺着你的思路讲，很少反对你的方案；Codex 写后端时会主动挑战你，它觉得不对的地方不会跟着你走。写后端代码，你要的就是这种被质疑。

二、别用一套流程打所有需求：任务的四象限

很多人用 AI 编程效果不稳定，根因是用同一套流程去打所有类型的任务。我梳理过一个判断框架，按两个维度分四象限：复杂度（是否需要技术调研、有多少复杂逻辑要处理）和改动量（涉及多少文件、多少处代码）。

最容易被低估的是低复杂度、大改动量这一格。举个我真实踩过的例子：页面上有很多富文本编辑器，我要把它从一个开源库换成另一个。这需求简单到不需要思考，但无论用简单提示词还是 Plan/Build 模式，它总会改漏几处。而让我手动拆几十个任务又太费劲。

后来的解法是：先让它梳理出所有需要改动的页面，为每一处改动建一个 to-do 项，然后按 to-do list 一条一条执行。 效果明显好过一句提示词直接改。这一格的关键不是「想清楚」，是「别漏」。

高复杂度、大改动量那一格没有捷径，必须拆分任务，一次做完几乎不可能。前面那个 10 个接口的项目就在这一格。

至于任务由谁来拆，这也是学员当场问到的：是让 AI 帮你拆，还是你自己先有意识地拆？我的答案是看你对技术方案有没有把握。如果这件事我脑子里已经很清楚该怎么做，只是改动量大，那让 AI 帮我拆就是多此一举——我直接开多个对话窗口，一个窗口安排一个任务。反过来，如果是从 0 到 1 的东西，需求分析我都想让它参与，那就一路让它做到底。

三、SDD 正在被模型能力吃掉：Plan + Goal 才是当下的主流

这一段是当晚学员最有反应的部分。他装了 SDD 类插件，一做什么东西它就开始生成一堆 spec、拆一堆 task 再去做。我的建议很直接：现在可以卸载了。

我在公司内部推过 SDD，不是用现成框架，是自己写的一套。用下来有几个非常典型的问题，最刺眼的一个：所有任务都要走一遍 SDD 流程，一圈跑下来可能要半个小时。太不灵活了。改个小模块，一句提示词丢过去让它改就行，没必要走全流程。

但真正让我判断「SDD 这条路在当下性价比不高」的，是模型能力的变化。现在的旗舰模型比半年前强非常多，而且强在一个关键点上：它已经把 SDD 那套结构内化成模型自身的能力了。

以前它写完代码就结束。现在几乎所有编码类任务，它写完会自己调用浏览器打开验证，失败了自己改，改完继续测。你要的「分阶段、有产出、可验证」，它自己就在做，只是不再需要你在外面用一层框架把它框起来。而每个阶段生成一堆文档，本身就是时间和 token 的双重消耗。

我现在的实际打法是两步。

第一步，Plan。 用推理能力强的模型出技术方案，出完再用另一个模型（我一般用 Codex）review 一遍这份方案。这一步你可以照旧让 AI 跟你多轮对话澄清需求、提问、细化——学员当场就理解对了：这相当于我们做敏捷时的需求澄清阶段，产出一份方案作为下一步的输入。

第二步，Goal 模式。 Codex 里的 Goal、Claude Code 里对应的目标模式，都是为长程任务设计的：你给它明确的目标和验收条件，它会不断 loop，直到验收条件达成为止。

Goal 模式最核心的东西是验收条件。 它要靠这个判断任务到底完没完成，所以你必须能定性地描述清楚「怎么算做完了」。技术方案里一定要包含这部分，而且要包含「怎么验证这个接口做对了」——说白了就是自动化测试。把这个写清楚丢进 Goal，它就能一次性跑完，中间自己测、自己改、自己再测。

这里有个对做过敏捷的人的红利：Story 的验收条件（AC）你本来就会写。 会写 AC，你就已经掌握了用好 Goal 模式的核心能力。

Goal 模式的 token 消耗确实偏大，但换来的是它不会偷工减料。相比 SDD 每个阶段生成一堆中间文档，我认为这笔账划算。

四、程序员最没打开的一环：设计

聊到这里，学员说了句实话——他之前做设计的时间很少。这是大多数后端和交付岗的共同盲区，也是现在性价比最高的一块补位。

三个可以立刻用上的实践。

第一，先穿刺，再全量。 生成 UI 之前，别直接说「帮我做一个完整的原型」。我的提示词是这样的：帮我生成一个 XX 的 demo 原型，先给我生成 3 个不同的 UI 设计方案，我拍板之后再完成所有的原型设计。学员一句话点破本质：这就是做一个穿刺。道理很简单——一次性跑完整原型，token 烧完了才发现 UI 风格不是你想要的，那才是真浪费。

第二，用前端 UI 类的 Skill。 不加任何 Skill 时，大模型会用它自己的习惯风格生成——那种靛蓝色、那种渐变色，一眼就能看出是 AI 做的，因为它训练数据里就带着这些习惯。而 UI 类 Skill 里沉淀了大量组件和设计规范，第一版出来的质量就明显高一档。我当场用同一个需求跑了两遍给他看：不加 Skill 的那版，用旗舰模型其实也已经挺好看了；但加了 Skill 的那版，是有自己的设计主张的——他的原话是「有些心思在里面」。

一个提醒：如果你用的模型本身审美已经在线，差异会被拉平一些。想看清 Skill 的价值，用能力弱一点的模型对比，差别会明显得多。

第三，专门的设计工具。 Claude 自带的 Design 能力（桌面端首页就能进）已经出来几个月了，PPT、文档、线框图、移动端 APP、视频、简历、3D 模型都能做，生成的东西我认为已经到了生产级别的审美程度。我用它做过课件 PPT、公司品牌介绍、产品使用说明书（可以直接基于代码仓库生成，很快）、朋友圈知识卡片。如果你想接任意模型而不只是 Claude，可以看 Open Design，底层能配 Codex 或其他 API，不挑模型——token 紧张时这是个很好的替代。

顺带说个把设计能力沉淀下来的通用套路，也是我做 Skill 的主要方式：80% 的场景我都是先手动跟它聊一遍，跑出一个我满意的效果，然后一句「帮我提炼为 Skill」。 比一开始就凭空设计 Skill 靠谱得多。

再进一步，Claude 自带的 Skill generator 缺了一环：它只基于你的需求生成，不会去参考行业内已有的最佳实践。我现在用的是社区里一个更完整的方案，它会先去 GitHub 上找有没有同类 Skill、别人的最佳实践是什么，学回来之后再形成最终的 Skill，效果好不少。或者干脆把 Skill 当成一个 feature 来做——用强模型 Plan，再用 Goal 模式生成。学员当场总结得很准：「就把它当成一个 feature，不是一个项目来做。」

写在最后

AI 编程这件事，卡住大多数人的不是知识密度，是「贯穿」。你知道原型可以生成，知道任务要拆，知道有 Goal 模式，但这些点在你手里没有连成一条线，落到真实项目上就会断。上面每一块单独看都不难，难的是从原型到接口契约、到任务拆分、到验收条件，一路不掉链子地走完一遍。

而这一条线，只能在真实项目上走一遍才长在你身上。

一对一辅导，开放少量名额

如果你也在做 AI 编程，想从「零散改片段」升级到「完整端到端交付」，欢迎找我聊一次。

怎么找我：公众号后台发消息「辅导」，说一下你目前最想解决的问题——是原型和需求的对 接，还是任务怎么拆，还是后端如何用 AI 保证质量。我看完会回你能不能帮上忙。

如果这篇对你有用，点个「在看」或转给那位也在用 AI 编程的朋友。

这是「辅导实录」系列第 01 篇，后面每次辅导我都会把可复用的部分整理出来。关注我，不错过后续。