普通人与 AI 协助开发项目的完整闭环（附全套提示词 PDF）

什么是工程思维：从指挥AI到成为Builder

这个国庆，我跟 GPT 好好聊了聊，话题是：什么是工程思维？不是写代码那些底层的工程技术，那些我觉得不用学。我说是如何与AI协助，也就是如何指挥AI干活。

聊完有不少感想，今天把过程写出来，如果你正在学习如何用好AI，肯定对你有用，最后还有一份成果。

就是一套与AI协助的提示词。与 Agent 协作各个阶段（这里Agent是指类似Workbuddy、Codex、DSH、Zcode这些智能体，别被这些词吓住，其实都差不多，就是你说它做的电子员工，正常说话就行），能用得上的提示词，我全部整理好了。

从教培平台实践出发的闭环需求

我现在一家教培机构，为了同事们能更好的使用机构的AI能力，我做了一个 AI 支持平台。平台里面，我准备了不少 Agent 协作相关的功能模块。有老师的工作台，报名续费入口，还有智能出卷、智能审卷。后面还打算加上智能问答这类模块，慢慢把它做成老师们日常办公能用的平台。

但是平台开发完，实际使用的时候，总会冒出各种问题、各种报错。要么登不上系统，登录进去又导不出数据，还有扫码扫不了之类的情况。

“修旧出新”倒逼出的工程闭环

做工程的时候，我发现一个很现实的现象。有时候，我好不容易修好一个 bug，当时问题解决了。可同事实际去用的时候，又会跑出来新bug。很多时候，这个新问题，就是修旧问题的时候顺带带出来的。我管这个叫 “修旧出新”。修好旧 bug，冒出新 bug。所以想着，得补一补工程思维这块的基础。正好趁着国庆，就找 GPT 聊，什么是工程思维。

跟 GPT 对话的时候，我问它什么是工程思维。它一层一层往下拆解，一直挖到很底层的东西。聊到最后，我们落到一个词：builder。它一路问到，我最终想成为什么样的人。聊到这一层的时候，我感觉收获特别大。我说，我想做一个 builder，一个构建者。

在现在这个时代，有 AI 帮忙之后，我们每个人的能力边界都被打开了。很多时候，限制我们的不是能力，而是敢不敢动手做。说白了，就是野心。只要你有野心，加上 AI 协助，你就不再只是一颗螺丝钉，不再是机器链条里面小小的齿轮。你的能力边界，可以扩得很大。但这里有个前提，就是你要懂得怎么和 AI 协作。这就是 builder 底层的思维。

Builder项目闭环的七个关键环节

聊天的时候，GPT 帮我重新梳理了一遍。梳理完，我总结出一套闭环思路，我手画了一个流程图让它帮我总结。

寻找需求

我们做 builder，做搭建，第一步就是找需求。需求大致分两类：

• 自发发现：builder 自己在日常工作、生活里发现的问题和痛点。
• 被指派：领导、同事或者客户提出来的需求，需要你落地实现。

验证需求

找到需求之后，作为 builder，你要先验证。看看这个需求是不是真实存在，是不是真的值得去做。这一步，就可以和 Agent 沟通，一起验证需求。需求来源于真实的物理世界，来源于人。但是，这个需求到底有没有价值、成不成立，属于逻辑层面的事，可以交给 Agent 一起讨论协作。至于现实世界里人的情绪感受，这个 Agent 是处理不了的，得靠我们自己判断。这第一轮，就叫验证需求。

编写 PRD

需求验证没问题，就让 Agent 写需求文档，也就是 PRD。

制定开发计划

有了 PRD 之后，找一个能力更强一点的 Agent，背后对应的是更强的大模型。拿着这份需求文档，让它输出开发方案，也就是开发计划。可以让它规划好：需求怎么落地，需要哪些资源，有哪些外部依赖，大概排期多久。AI 输出的这份计划会很专业。像我这种非科班的人看，都会觉得有点难懂。而且我觉得，也没必要花大量时间死磕这份文档。意义不大，毕竟再怎么看，也很难比 AI 考虑得更全面。

审核方案

所以到这一步，我一般会把这份开发文档，交给另一个 Agent。重点：必须换一个，而且上下文窗口要隔离，也就是新开一个 Agent 窗口。举个例子，我可能在 Codex 里调用 Kimi K3 模型生成开发文档。文档写完，我要检查有没有问题。AI 有局限性，不能直接采信。我会换到 zcode 里面用智谱模型去审核，找找里面的毛病。经过这一轮审核，一定会提出不少问题。根据我的经验，100%会有问题，不可能一次就全部通过。记住一点，所有项目产出，审核的时候基本都会发现问题。AI 第一次产出的东西，绝对不能直接拿来用，一定存在漏洞。审核 Agent 把问题和疑问一条条列出来之后，再把这些反馈给到原来的开发 Agent，让它补充、回复。接着，再把它的回复，交回审核 Agent 复查。这个过程，一般要来回 2～3 轮，甚至 3～4 轮。反复迭代，直到敲定最终版本的开发方案。

人工拍板

开发 Agent 输出的文档，全是技术栈这类专业内容，我不愿意读。这时我会让审核 Agent，用简单的话给我解释清楚。告诉我，这份方案整体是什么结构。审核 Agent 就用大白话讲给我听，我再自己理解一遍。只要逻辑没问题就行。就算我不懂代码，我也能看懂整个逻辑：先做什么、后做什么，为什么要这么做。底层逻辑和现实世界是相通的。

执行计划与审核验收

确认好之后，我就把这份开发计划，直接丢给执行 Agent，比如 DSH+DeepSeek，让它执行。执行完成会产出结果，产出之后，再交给审核 Agent 再审核一次。这里补充一句：做计划、做审核的全程，每一次和 Agent 沟通，都要用到提示词。这些提示词我后面都整理好了。审核的时候，不同 Agent 考虑问题的完整度不一样。但不管是谁，我在提示词里都会明确要求：不管是做方案设计，还是做审核的 Agent，都必须评估上下依赖关系。评估这次改动、这次设计，会不会影响原有系统链条和流程。从这个角度入手，就是为了避免前面说的 “修旧出新”。在设计阶段，就提前规避修好旧 bug，带出一堆新 bug。所以我所有提示词里面，都会带上这个要求，让 Agent 层层考虑。

支撑闭环的两大知识资产

聊到怎么避免 “修旧出新” 的时候，GPT 还给了我启发。想要做到这点，需要维护两样东西。

开发迭代史

记录项目从开始到后面，每一次改动，为什么要这么做。后续升级、调整，背后的逻辑是什么。像编年史一样全部记录下来。这份记录，可以给 Agent 下一次调整的时候作为参考。好处有两个： (a) 不会再踩之前已经踩过的坑。 (b) 清楚系统现在为什么是这个样子。后续调整的时候，知道哪些地方可以改，哪些地方不能破坏。

历次运行日志

保存系统历次运行日志文档。记录系统运行时出现的错误、问题，还有成功经验。包括报错发生的时间，以及问题产生的原因。这两份资料，会作为后续开发的上下文。Agent 开发的时候，可以知道这个系统是怎么一步步来的，之前出过哪些问题。开发的时候，就不会重复踩旧坑。从设计层面，减少 “修旧出新”。

闭环终点即起点：人工验收与持续迭代

我们再说回执行 Agent。对执行 Agent 的要求：严格按照开发文档和开发计划执行，同时参考需求文档。

执行 Agent 产出的内容，交给审核 Agent。执行和审核之间，要做到物理隔离。给它们的提示词也会写明这个规则。审核 Agent 要保持独立身份，不能被执行者的上下文、开发思路带偏。审核 Agent 只看执行者的产出物。对照需求文档、开发计划，核对是否匹配。用独立逻辑去做审核。这个过程，执行和审核之间肯定还会发现问题，同样要来回沟通两三个回合。

几轮下来，交付给我之后，我自己先测试一遍。我亲自跑一遍，然后小范围找几个同事试用。没问题之后，再全面放开，给到所有用户使用。到这里，流程还没有结束。系统正式上线使用之后，百分百还会遇到预料之外的问题，也会冒出新的需求。这些新问题、新需求，会回到最开始，变成新的需求。再重新走一遍需求验证、方案设计这套流程。整个流程就形成了闭环。这就是 Builder 做项目的完整闭环（Loop）。

这次国庆和 GPT 的对话，我已经把闭环里每一环，和 Agent 沟通要用的提示词全部整理好了。有需要的朋友可以自取。

希望你能不断地拓展自己的能力边界。

JOTO 企业落地观察

• 企业部署AI智能体时，若缺乏跨Agent角色隔离机制（如开发/审核分离、上下文隔离），将难以规避“修旧出新”类系统性风险；该闭环强制要求物理隔离与多模型交叉验证，直指当前RAG与智能体工程中知识一致性薄弱的痛点。
• 开发迭代史与运行日志并非辅助文档，而是智能体持续演进的“记忆锚点”；企业若未将其结构化沉淀为知识图谱或向量库，AI在后续迭代中无法真正理解系统演化逻辑，导致提示词失效或幻觉加剧。
• 该闭环中“人工拍板”环节本质是人机认知对齐：非技术人员通过大白话解释获得逻辑主权，而非技术细节主权；这对FDE驻场共创提出明确要求——需配备能翻译AI输出、建立业务-技术语义映射的中间角色。
• 全流程提示词标准化，是企业级AI工程化的基础设施；但提示词有效性高度依赖上下文资产质量，企业若仅复用通用模板而忽略自身迭代史与日志的注入，将导致智能体决策脱离真实系统状态。