企业官网建设流程全解析

上个月，一个做后端的朋友丢给我一份PDF，说：“这本入门手册你要是能一口气看完，我请你吃饭。”我一开始真没当回事——“入门”两个字在技术圈早就被用滥了，绝大多数标着入门的资料，拆开无非是教你装环境、调接口、跑通一个demo，然后就没有然后了。结果那天晚上我翻到第三章就坐直了，翻到中间讲规则设定的部分直接给他发了条消息：这顿饭我请，而且我想写篇长文聊聊这本书。

准确说，我跪着读完的不是一本厚书，而是一套关于AI工程的自学手册。它讲的核心东西就三块：提示词工程、AI写代码时的规则设定、以及把它们串起来的AI工程实践闭环。听起来都是老生常谈的词，但这本书的狠劲在于，它不教你怎么“调用AI”，而是教你怎么把AI当成一个正经的工程系统去设计、开发、测试、上线。这篇文章不打算复述目录，我只讲自己读完以后真正留下来、并且立刻用到工作里的东西。

1. 一本标着“入门”的手册，凭什么让干了好几年活的人跪着看完

1.1 被“入门”两个字耽误的好书

我一度很抵触“AI工程”这个说法。干过几年软件开发的人都知道，“工程”两个字意味着什么——需求分析、架构设计、单元测试、代码评审、灰度发布、线上监控，缺一个都不能叫工程。但市面上大多数AI教程连“工程”的边都没沾，教的是怎么把一段话写得让模型更听话，本质上还是玄学。

这本手册开篇就干了一件狠事：它直接把AI工程定义成“把大模型能力变成可交付、可维护、可评估的系统行为”，而不是“用AI写几个脚本”。整本书默认你是个能写代码的工程师，但不懂AI工程是怎么回事，然后从第一性原理开始，把一套完整的工程方法一点点搭给你看。

书里有个比喻我到现在还记得：把提示词当说话技巧的人，和把提示词当代码来管理的人，差别就像街头卖艺的和建筑公司施工队——前者每次发挥看手感，后者要按图纸施工、有验收标准、出问题要能追责。这个类比一下就击穿了我之前对提示词的模糊认知。

1.2 开篇第一个观点就让我停下来

手册引言里有一句话，原话我记不全了，大意是：“AI工程的第一个误解，是以为难点在模型；第二个误解，是以为难点在提示词；真正的难点，在于你周围根本没有一套系统，能告诉你这次改动到底变好了还是变坏了。”

这句话我反复看了好几遍。回想我自己之前用AI写代码的经历，确实就是这个状态：今天觉得加一句“请认真思考”效果不错，明天觉得换个措辞更稳，但到底哪个版本更好，我说不上来，全凭感觉。手册管这叫“提示词手感依赖症”，并直说这种状态不叫实践，叫玩。

它建议所有想认真做AI工程的人，第一天就要接受一个观念：提示词工程不是写作文，是写协议。你写的每一段系统提示词、每一条规则，本质上都是在定义一套输入输出协议，而协议就必须有版本、有测试、有回归。这个思路贯穿全书，也是我整本书跪得最彻底的地方。

1.3 这本书回答了我一直没想明白的问题

我过去经手过几个AI项目，demo阶段个个惊艳，一进生产环境就翻车。要么是模型输出不稳定，要么是跑几天之后没人敢改提示词——因为一改就崩，改了也不知道是哪句话引起的。我一直归咎于“模型不够聪明”，但这本手册指出了真正的原因：我从来没有为模型输出建立质量门禁。

书里给了个很扎心的总结：demo能跑通，说明模型有能力；生产能活下来，说明你的工程体系有能力。而绝大多数AI项目的死因，不是模型不够强，是工程体系为零——没有评测集、没有回归测试、没有输出护栏、没有人对每一次prompt改动负责。

看到这里我已经完全服气了。这本手册不是在教你追新模型，而是在帮你补上一整套AI时代工程师本该有的基本功。

2. 提示词工程：从“说话玄学”变成“可复现协议”

2.1 先认清一件事：提示词就是代码

手册花了整整一章讲提示词工程，但我最受益的不是那些花哨的技巧，而是一个底层认知转换：把提示词当成代码，而不是当成话术。

代码有什么特征？有版本、能测试、会评审、可以回滚。提示词如果也是代码，那么你每一次修改都必须回答三个问题：这次改动的预期效果是什么？用什么用例来验证效果？如果效果变差了，怎么回退？

为了做到这一点，手册要求给每一条系统提示词建立自己的“变更记录”。我自己实践下来，最简单的做法是一个表格：

这看起来很简单，但它改变了我过去那种“改一次忘一次”的坏习惯。提示词一旦进入版本管理，后面所有问题都有了排查锚点。

2.2 五个直接能用的提示词模式

手册里给的提示词模式很多，我挑出五个在我日常工作中真正常用的，每个都配最简单的使用场景。

模式一：结构化系统提示词。别再把所有要求塞进一句话里，而是分字段写：

角色：资深后端工程师 任务：实现用户模块的Token刷新接口 上下文：项目使用Python 3.11 + FastAPI，已有auth_service.py 约束： - 只修改auth_service.py，禁止改动其他文件 - 必须使用项目现有的日志规范 输出格式：先给实现方案，再给完整代码，最后列风险点

这种写法最大的好处是可维护。模型出问题时，你能快速定位是角色设定错了，还是约束没写清。

模式二：少样本示范（Few-shot）。光说“写得好一点”没有意义，直接给一个你心中的优秀示例，让模型对齐你的口味。比如让它写commit message：

参考以下两个示例的写法来写： 示例1：fix(auth): 修复刷新Token时未校验过期时间的缺陷 示例2：feat(order): 新增订单超时自动关闭任务，附带补偿机制

给它两个正例，往往比给它十条抽象要求有效得多。

模式三：先计划后执行。对稍微复杂的任务，强制模型先输出计划再执行。这不是什么高科技，但它能大幅减少模型做到一半跑偏的概率。

先列出你完成这个任务的具体步骤（不超过5步）， 等我说“开始”之后再逐步执行，每一步都说明你做了什么。

模式四：自我校验。让模型在给出答案前先检查一遍自己的输出。尤其是生成代码时，这个模式能捞回不少低级错误。

完成代码后，列出这段代码可能存在的边界情况， 并说明你的代码是如何处理这些边界情况的。

模式五：输出格式锁定。这条最实用，凡是程序要解析的输出，一律指定结构。我用得最多的就是把输出锁成JSON：

只输出JSON，格式如下： {"summary": "<概要>", "issues": [{"severity": "high|medium|low", "description": "<描述>"}]} 不要输出任何解释。

这五个模式单看都不惊艳，但组合起来就是一套完整的提示词工程底座。我现在的所有系统提示词，基本都由这五类元素拼装而成。

2.3 提示词也要评测：我学到的“改词”方法论

手册里最颠覆我认知的一句话是：“如果你改了一版提示词，却说不清它比上一版好在哪，你就不该改。”

它给出一套很朴素的方法：每次改动前，准备一组覆盖典型场景的测试用例（不需要多，20到50条就够），然后跑新旧两个版本，对比通过率、输出质量、以及跑偏样本的数量。我在自己的小项目里试了一下，选的标准很简单：每个测试用例预先写好一个“可接受输出”的描述，模型输出与之匹配就算通过。

这套方法论最值钱的地方在于，它把“我觉得变好了”彻底赶出了工作流。从此每一次提示词改动都有数据支撑，后来线上出问题需要排查时，翻版本记录比翻聊天记录靠谱太多了。

3. 规则设定：让AI写代码时不撒欢的真正手段

3.1 为什么AI写代码必须配规则而不是自由发挥

很多人第一次用AI写代码的感受是“真香”，用一个月之后的感受是“真累”——因为AI写出来的代码就像个天赋很高但没有纪律的新人：能跑，但风格混乱、乱改无关代码、时不时给你幻觉出一些根本不存在的API、还不写测试。

手册讲了一个我特别有共鸣的场景：有一次AI为了完成一个“读取配置”的小需求，顺手“优化”了好几个不相关的函数，还把项目原有的配置结构推倒重来。功能确实跑通了，但我code review时差点血压拉满。自由发挥的AI写代码，就像让一个新员工在没有开发规范的公司里干活——他不坏，但他不知道边界在哪。

所以手册的核心主张是：给AI写代码，规则的重要性远高于才华。提示词是激发模型能力的油门，规则是控制方向的刹车和护栏，两者缺一不可。

3.2 一套可以直接抄的AI编码规则模板

手册里给了一套编码规则的分类框架，我按自己的理解整理成了五类，几乎可以平移到我目前用AI辅助开发的流程里。

第一类是范围控制规则。明确告诉AI可以碰什么、不能碰什么：

规则1：只修改任务描述中明确提到的文件。 规则2：禁止重构与任务无关的既有代码。 规则3：禁止替换项目已有的第三方库和工具链。

这一条能避免AI最令人头疼的“顺手优化”。

第二类是编码风格规则。把团队的代码规范直接翻译成规则语言：

规则4：所有新增函数必须带有类型注解和docstring。 规则5：函数体超过50行时，必须拆分子函数。 规则6：禁止裸except，必须捕获具体异常并记录日志。

第三类是测试规则。这是我自己原来最容易漏的：

规则7：新增逻辑必须配套单元测试，关键分支覆盖率不低于80%。 规则8：测试用例必须覆盖正常路径、异常路径和边界条件。

第四类是信息输出规则。让AI在交付代码时同时交代清楚：

规则9：先输出改动方案，再输出代码，最后列出风险点。 规则10：如果实现过程中遇到与设计不符的情况，停止并说明原因。

第五类是安全底线规则，这个看项目而定，比如禁止硬编码密钥、涉及用户输入必须做参数校验。

这套模板我直接复制进了自己的AI编码系统提示词里，实测效果立竿见影——最大的变化不是代码变好了，而是AI开始“讲道理”了：它会在动手前先告诉我它打算怎么改，改完会主动列风险点。这让我从“给AI擦屁股”的状态里解脱出来。

3.3 规则系统的三原则：可执行、可检查、可迭代

规则不是写得越多越好。手册里有句话很关键：规则过多会让模型无所适从，最后变成每条都遵守一点、每条都不彻底。

它对规则系统提出了三个检验标准，我把它当成自己的规则验收清单：

可执行。每条规则都得是模型能在生成文本时实际照做的。比如“请写出高质量的代码”就不可执行，因为“高质量”是个抽象形容词，而“所有函数必须带类型注解”就可执行。

可检查。你不能光靠“看感觉”判断AI有没有遵守规则。风格类规则可以靠lint工具检查，测试类规则可以靠覆盖率工具检查，输出格式可以靠解析器检查。规则如果没有对应的检查手段，就等于没写。

可迭代。规则系统要有反馈回路：某个错误反复出现，就新增或强化一条规则；某条规则导致输出明显变差，就果断删掉或降级。

我自己的做法是，每一轮AI编码任务结束后，顺手记录两条：这次哪类错误最多、哪条规则形同虚设。攒到十个错误样本就集中调整一次规则。这个习惯让我的规则系统越来越像一份活的编码规范，而不是一个死板的模板。

提示：如果你只想从这篇文章里带走一件事，那就是这句——给AI写代码，永远先定义“不许做什么”，再定义“要做什么”。

4. 手册里最硬核的一章：AI工程的完整闭环

4.1 从“会生成”到“能上线”之间缺什么

全书最让我震撼的是中间偏后的一章，题目大意是“AI工程不是生成，是闭环”。它把一次完整的AI工程实践拆成了六个环节：需求定义、生成实现、结果评估、回归验证、部署上线、线上监控。

这六个环节单看都不复杂，但我在现实中见过太多团队只做了中间两个——拼命调prompt、拼命生成结果，然后直接扔给用户。手册很毒舌地点破：这种流程连软件工程里的“开发”都算不上，因为没有测试、没有验收、没有回滚机制。

它画的那个闭环（文字描述的）我至今记得很清楚：需求定义要写成“可评测的验收标准”，生成实现要对照验收标准检查，评估通过才进入回归，回归通过才允许上线，上线后的失败样本又回流到需求定义里形成新一轮迭代。这个循环一旦转起来，AI项目才真正有了“工程”的样子。

4.2 把模型输出当代码管：版本、回归、灰度

这章最实用的部分，是把软件工程里的成熟实践平移到大模型输出管理上。我整理成了一个对照表，帮助自己理解：

这个表对我最大的启发是：以前我总觉得AI项目“特殊”，不能用传统经验；实际上，它比传统项目更需要纪律，因为模型输出比人写的代码更难预测。手册的做法是把不确定的东西尽量变成可观察、可度量的东西。

4.3 没有评测体系的AI工程都是演示工程

这一节我愿称之为全书最值得跪的部分。它反复强调一个观点：没有评测体系的AI项目，无论效果多惊艳，都只是昂贵的demo。

它给的评测思路很接地气，不要求你上机器学习那套复杂指标。针对大多数业务场景，先做三件事就够：

第一，建一组固定的测试用例，覆盖你系统最核心的输入类型和边界情况，数量不用多，但要精。第二，给每条用例预设“可接受的输出标准”——注意不是唯一答案，而是一段描述，方便判断模型输出是否达标。第三，每次改动都跑一遍这组用例，记录通过率。

更进一步的指标是分层看：所有用例的通过率是一个数，但你要单独看高风险用例的通过率——因为一个在普通场景全对、在敏感场景出问题的系统，是不敢上线的。手册里管这叫“别让平均数掩盖灾难”。

这套思路我立刻用了起来，后文会讲我的具体实践。它让我第一次对AI输出有了“心里有底”的感觉。

5. 读完书我立刻做的AI工程实践：一个带规则约束的代码评审助手

5.1 为什么选代码评审这个场景

书读到一半我就坐不住了，决定立刻照它的方法论做一个真实的AI工程实践。选来选去，我挑了一个自己每周都在做的事：代码评审。原因有三——场景足够刚需且高频，输入输出边界非常清晰，而且容易做评测。

我的目标很朴素：让AI看Git的diff文件，输出评审意见，但意见必须符合我定的规则，不能瞎提、不能刷存在感、更不能幻觉出不存在的问题。

5.2 系统提示词与规则的第一版

基于手册的框架，我写了第一版系统提示词，核心结构长这样：

角色：资深代码评审专家 任务：基于给定的Git diff，输出代码评审意见 输入：一段git diff文本 规则： - 只评审本次diff涉及到的改动行，禁止评审diff之外的代码 - 每一条意见必须对应到具体的行号和问题描述 - 按严重程度分级：high表示可能导致bug，medium表示可维护性问题，low表示风格建议 - 如果你对某处问题没有确切把握，必须标记为“疑似”并说明原因 - 禁止输出无实质内容的赞美或客套话 - 禁止编造不存在的API或安全隐患 - 同一类问题合并输出，不重复刷屏 输出格式（JSON）： {"summary": "...", "comments": [{"line": 12, "severity": "high", "message": "..."}]}

这一版已经比较接近手册里的“可执行、可检查”标准了，但我实际跑完第一轮就知道还有差距。

5.3 实测数据和两轮迭代

我拿一个真实PR的diff做测试，第一次跑出来的结果让我有点失望：AI一共提了14条意见，其中3条是误报——它把并不存在的并发问题说得头头是道，属于典型的幻觉式评审。

按照手册的评测方法论，我认真分析这3条误报的共同特征，发现它们都发生在AI对业务流程理解不深的场景。于是我做了一次规则迭代，新增两条硬规则：

- 禁止以“可能存在并发风险”等推测性语言提出未经代码逻辑证实的问题 - 如果问题涉及本次diff之外的上下文，必须先说明你的推断依据

同时，我把“必须以行号为锚点”从规则提升到了输出格式强制项——凡是没有行号的意见，解析器直接丢弃。

第二轮评测的结果是：总意见数从14条降到9条，误报从3条降到1条，剩余那1条也明确标记了“疑似”。我还顺手测了一下“禁止客套话”这条规则——确实有效，AI不再在summary里写“整体代码质量很好”这类废话了。

这次实践让我彻底相信了手册的核心主张：AI的输出质量不是靠换更强的模型解决的，而是靠规则设定和评测循环一点点磨出来的。

6. 诚实测评：这本书哪些篇章值得二刷，哪些可以扫读

6.1 值得反复读的篇章

如果让我排序，第一优先是讲评测方法论的那章。它不教你具体指标，而是教你“怎么分辨一次改动到底有没有变好”这个底层能力，这个能力适用于所有AI项目。

第二优先是讲规则设计的部分。它的价值不在于给模板，而在于讲清楚了规则系统的三个检验标准——可执行、可检查、可迭代。我后来自建的所有AI工具，规则部分都是按这个框架设计的，翻车率明显降低。

第三优先是完整闭环那一章。它把从需求定义到线上监控的全链路串起来了，很多零散的知识——提示词版本、评测集、回归测试——到了这一章才算真正有了位置。

6.2 可以快速扫读的部分

诚实说，书里关于某些具体工具和平台的章节，我是跳着看的。一是因为工具迭代太快，手册写得再及时也会过时；二是因为那些内容本质上属于“说明书”，需要的时候查一下就行，不值得精读。

还有一些偏模型原理的章节，如果读者的目标只是把AI用进工程里，理解个大概就够了。这不是说原理不重要，而是对多数人的首要任务来说，先把工程闭环跑起来，再回头补原理，效率更高。

6.3 这本书的边界与我的不同意见

最后说点不同的意见。这本手册整体很硬核，但它有两个明显的时代局限。

第一，它默认读者有稳定的模型API访问渠道和一定的预算额度。自托管模型或者离线场景，手册里着墨很少，如果你属于这类场景，需要额外补知识。第二，书里对“提示词工程”的权重给得非常高，对微调和小模型方案基本一笔带过。我的看法是，提示词工程确实是性价比最高的起点，但当一个场景稳定跑通之后，考虑用更小的模型配更精简的提示词来降本，应该成为一个进阶方向——这一点手册没有充分展开。

另外说句玩笑话，这本书的标题叫“入门”，但它对读者的要求是懂代码、懂基本的软件工程概念。如果你是纯零基础想学AI工程，我建议先补一点Python和命令行知识再回来读。它的“入门”，是给已经有工程底子的人入AI这个门。

最后说点个人的体会。我读完这本手册到现在一个多月，最大的变化不是我会写更花哨的提示词了，而是我手头每个AI相关的小工具都开始有了自己的评测集和规则清单。我前两天在群里跟朋友说：过去我是碰运气用AI，现在是照着图纸施工。如果你想认真做 AI工程实践，建议你也记住那条最核心的原则——提示词工程管生成，规则设定管边界，评测闭环管质量，这三样凑齐了，你才算真正开始做AI工程，而不是在玩AI。