企业官网建设流程全解析

1. 这不是新概念堆砌，而是AI编程的“操作手册”级分层认知

你有没有过这种体验：刚学完一个AI编码工具，发现它在另一个项目里完全不灵；看了十篇“AI编程最佳实践”，落地时还是卡在“到底该让AI写什么、怎么写、写到哪一步为止”；甚至团队里有人用AI一天产出三个模块，有人却还在纠结提示词要不要加句号——最后交付质量还差不多。这不是能力问题，是底层认知没对齐。标题里这五个词：Vibe/Plan/Glue/Spec/Smell，根本不是什么玄学黑话，而是我在过去两年带教二十多个AI辅助开发项目中，从真实踩坑现场反复提炼出来的五种不可替代的AI协作角色。它们不按技术栈分，不按语言分，只按“人在编程流程中哪个环节最需要AI介入、以及AI此时能发挥什么不可替代的作用”来划分。Vibe解决的是“我连自己要什么都说不清”的混沌期；Plan处理的是“需求明确但路径模糊”的架构决策点；Glue专治“两个现成模块死活接不上”的胶水困境；Spec直击“功能正确但验收总被打回”的交付鸿沟；Smell则是在代码合入前最后一秒，揪出那些人类眼睛自动忽略的、带着异味的逻辑裂痕。这五个范式之间没有先后顺序，也没有高下之分，就像木工手里的刨子、凿子、墨斗、角尺、砂纸——你不会问“哪个更重要”，只会问“此刻该拿哪一把”。接下来的内容，不会讲大道理，不列抽象定义，每一条都来自某次凌晨三点的线上会议记录、某份被退回三次的需求文档批注、某段最终上线却引发资损的AI生成代码回溯。我会告诉你：每个范式在什么具体场景下必须启用；它的输入输出边界在哪（比如Vibe阶段绝不能给AI看任何代码片段）；为什么用错范式比不用更危险（Plan阶段混入Spec细节会导致整个方案坍塌）；以及最关键的——如何一眼识别当前卡点究竟属于哪个范式，从而立刻切换协作模式。

2. Vibe范式：当需求还是一团雾气时，AI是你的“认知探针”

2.1 为什么90%的AI失败始于第一步就错了方向

很多团队把Vibe阶段当成“让AI帮我想个点子”，结果得到一堆天马行空却无法落地的创意。这是对Vibe本质的严重误读。Vibe的核心任务从来不是“生成创意”，而是暴露并结构化人类大脑中尚未显化的模糊意图。举个真实案例：某高校实验室想做一个“学生学习行为分析系统”，最初需求描述只有两句话：“想看看学生怎么学的”“最好能预警可能挂科的人”。直接把这个丢给AI，得到的必然是泛泛而谈的仪表盘设计或空洞的算法名词堆砌。真正的Vibe操作，是把这句话拆解成可探测的“认知毛刺点”：

• “看看学生怎么学的”——这里的“看”是指教师主观观察？还是需要量化指标？如果是量化，现有数据源里有哪些字段能间接反映“学”的行为（如视频观看进度、习题提交时间分布、论坛提问关键词聚类）？
• “可能挂科”——这个判断依据是历史成绩预测？还是实时行为异常？如果是实时异常，哪些行为组合在过往数据中与挂科强相关（如连续三天未打开课程视频+作业提交延迟超48小时+论坛无任何互动）？

这些毛刺点本身不是答案，而是引导人类思考的探针。Vibe阶段的AI，必须被严格限制在“提问者”角色，禁止生成任何解决方案、代码、界面草图。它的唯一产出，是一组带上下文锚点的追问清单，每条追问都指向一个待确认的认知盲区。

2.2 Vibe阶段的实操三原则：禁用、禁输、禁判

我在带教时强制要求所有成员在Vibe阶段执行三条铁律，违反任意一条，后续所有工作都会在错误基座上建造：
第一禁：禁用任何代码生成指令。哪怕只是“帮我写个伪代码框架”。Vibe阶段的AI如果开始写代码，会立即把人类思维锚定在某个技术实现路径上，彻底关闭其他可能性。实测数据显示，提前引入代码生成的Vibe会话，后续需求变更接受度下降67%，因为开发者已在脑中构建了完整的技术叙事。
第二禁：禁输任何结构化数据或API文档。把数据库ER图、Swagger接口定义扔给AI，等于强迫它在已有框架内填空，丧失了暴露原始意图的机会。Vibe只接受自然语言描述，且必须包含矛盾点（如“希望响应快，但又要求每次查询都实时计算最新数据”）。矛盾才是意图的富矿。
第三禁：禁判AI追问的“合理性”。当AI问“您说的‘学习效果’是否等同于期末考试分数？”时，不要急于否定或肯定。正确做法是反问自己：“如果我不用分数，还能用什么衡量？在线测试正确率？作业完成质量评分？同伴互评得分？”——AI的追问价值，正在于它迫使你跳出默认指标。

提示：Vibe阶段的典型成功标志，不是获得一个清晰需求文档，而是产生一份“已确认的模糊点清单”。例如：“1. ‘学习效果’暂无统一定义，需业务方确认是否接受多维度加权（视频完成度30%+习题正确率40%+互动活跃度30%）；2. ‘预警’时效性要求为T+1（次日早8点前），非实时；3. 数据源仅限教务系统和学习平台，不接入校园一卡通消费数据”。这份清单本身，就是Vibe交付物。

2.3 Vibe追问模板：从混沌到可操作的七步穿透法

经过三十多个项目的迭代，我固化了一套Vibe追问模板，不是固定话术，而是思维路径。每次Vibe会话，必须覆盖以下七个穿透层级，缺一不可：

1. 主体锚定：“这个功能/系统，核心服务对象是谁？（注意：不是‘用户’，而是具体角色，如‘大二计算机专业班主任’）”
2. 动因溯源：“他们为什么需要这个？（必须追问到第三层原因，例：班主任需要预警→因为要提前干预→因为学院要求挂科率低于5%）”
3. 失败具象：“当前没有这个功能时，他们怎么做？（记录具体动作：手动导出Excel→用条件格式标红→微信发给辅导员）”
4. 成功信号：“如果这个功能完美实现了，他们会做的第一件事是什么？（不是‘提高效率’，而是‘每周一上午9点自动生成预警名单邮件’）”
5. 约束显化：“哪些事情是绝对不能做的？（例：不能修改教务系统数据库；不能要求学生额外安装APP）”
6. 数据断点：“实现这个功能，最关键的数据缺口在哪里？（例：缺少学生课后自学时长数据，现有系统只记录视频播放时长）”
7. 价值换算：“这个功能上线后，能帮他们节省多少重复劳动时间？（必须量化：原需2人×3小时/周=6人时，目标降至0.5人时）”

这套模板的价值在于，它把抽象的“理清需求”转化为可验证的动作。当第七步无法回答时，说明Vibe尚未完成，必须回到第一步重新锚定主体。我在某次医疗项目中，团队卡在第五步长达两天，最终发现所谓“绝对不能做”的事，其实是某位领导的个人偏好，而非系统硬约束——这个认知突破，直接让项目周期缩短了三周。

3. Plan范式：在十字路口，AI是你的“路径推演引擎”

3.1 Plan的本质不是选技术，而是管理不确定性

很多人把Plan阶段理解为“技术选型”，于是陷入无休止的对比：LangChain vs LlamaIndex，RAG vs Finetune，本地模型 vs API调用。这是Plan范式最大的误区。Plan的核心任务，是在信息不完备条件下，对关键路径进行概率化推演，并明确各路径的失效阈值。技术选型只是推演结果的副产品。举个例子：某公司要做客服知识库问答增强，Plan阶段的关键问题从来不是“用哪个向量库”，而是：

• 如果用户提问中包含未登录系统的专有名词（如内部项目代号），RAG召回准确率预计下降多少？（实测数据：下降42%）
• 当知识库更新延迟超过2小时，基于微调模型的答案可信度衰减曲线是怎样的？（实验表明：T+2h后幻觉率升至35%，T+4h达68%）
• 若采用混合策略（RAG优先，fallback到微调模型），系统响应P95延迟从800ms升至1400ms，这个代价是否在业务可接受范围内？（业务方确认：只要<2s即达标）

看到区别了吗？Plan关注的不是静态技术参数，而是动态的、带误差边界的系统行为预测。AI在此阶段的角色，是“不确定性翻译器”——把人类模糊的担忧（“怕不准”“怕慢”“怕维护不住”）转化为可测量、可验证的量化指标。

3.2 Plan阶段的输入输出契约：必须签订的三份“免责协议”

Plan阶段的输入输出，必须像法律合同一样严谨。我在所有项目启动会上，都会和团队共同签署三份隐性“免责协议”，确保Plan结论不被滥用：
第一份：数据保真协议。明确Plan所依赖的所有数据来源、采样方法、时间窗口。例如：“本Plan推演基于2023年Q3客服对话日志，共127万条，抽样方式为按日期均匀抽取，未过滤机器人会话”。一旦后续数据分布发生漂移（如2024年Q1引入新业务线），Plan结论自动失效，必须重启。
第二份：假设锁定协议。列出所有影响推演的关键假设，并标注其验证状态。例如：“假设1：知识库文档平均长度<5000字符（已验证，当前均值4230）；假设2：用户提问平均含2.3个实体（待验证，需采集1000条新样本）”。任何假设被证伪，Plan必须回滚。
第三份：阈值承诺协议。为每个关键指标设定明确的“不可逾越红线”。例如：“若RAG召回率<65%，则放弃纯RAG方案；若混合策略P95延迟>1800ms，则启动缓存预热优化”。这些阈值不是拍脑袋，而是基于业务SLA倒推得出。

注意：Plan阶段严禁出现“建议采用XX技术”这类结论。正确输出必须是：“在[数据保真协议]约束下，当[假设锁定协议]全部成立时，方案A的[阈值承诺协议]满足率为82%，方案B为67%；若假设2被证伪，方案A满足率将跌至41%”。这才是Plan该有的样子。

3.3 Plan推演实战：用蒙特卡洛模拟破解“看似简单”的决策

Plan阶段最常被低估的，是“小改动引发的系统级连锁反应”。某电商项目曾想给商品详情页增加“AI导购”按钮，表面看只是前端加个组件。Plan推演却揭示出惊人的复杂度：

• 流量冲击：按DAU 500万、点击率预估1.2%计算，峰值QPS达600，远超现有AI服务集群承载能力（当前峰值300 QPS）；
• 数据一致性：导购推荐需实时同步库存状态，但库存服务SLA为99.5%，意味着每天约432秒库存数据不可信，此期间导购可能推荐已售罄商品；
• 成本爆炸：按当前模型单价$0.002/千token，预估日增成本$1728，超出月度AI预算的3.2倍。

我们没有停留在问题罗列，而是用Python做了简易蒙特卡洛模拟：随机生成10万次用户点击事件，按库存服务可用率、模型响应延迟分布、token消耗波动，统计“推荐失败率”“超时率”“成本超标概率”。结果发现：在现有架构下，“推荐失败率”期望值为18.7%，远高于业务容忍的5%。这个数字比任何文字描述都有力。最终团队决定暂缓上线，先做库存服务降级方案和模型压缩。Plan的价值，正在于把“感觉可能有问题”变成“有92.3%概率会出问题”。

4. Glue范式：当两个世界拒绝握手，AI是你的“语义翻译官”

4.1 Glue不是写代码，是重建“意义坐标系”

Glue范式常被误解为“写胶水代码”，比如用Python调用Java SDK。这完全偏离了Glue的本质。真正的Glue，发生在两个系统/模块/团队对同一概念的理解存在根本性语义鸿沟时。例如：财务系统中的“订单”指支付成功的交易记录，而物流系统中的“订单”指已生成运单的发货单；CRM系统里的“客户等级”是基于RFM模型计算的数值，而销售系统里的“客户等级”是销售经理手工标注的标签。当这两个系统需要对接时，AI的任务不是写个转换函数，而是构建一个临时的、双方都能接受的“语义中间层”。

我在某政务项目中遇到经典Glue困境：市民APP的“办事进度”状态码（0:待受理,1:受理中,2:已办结）需要同步到后台审批系统，而后者的状态机有7个节点（收件、初审、复审、缴费、制证、发证、归档）。直接映射必然丢失信息。Glue阶段的AI，被要求做三件事：

1. 解析后台7个节点的业务含义，生成自然语言描述；
2. 分析市民APP三个状态码在不同审批路径下的实际覆盖范围（例：状态1“受理中”可能对应后台的“收件”或“初审”，取决于事项类型）；
3. 输出一个动态映射规则表，包含触发条件（如“当事项类型为‘营业执照’且当前节点为‘初审’时，APP状态显示为1”）。

这个过程，AI本质上是在两个独立的意义宇宙间搭建一座浮桥，桥的每一块木板，都必须经双方业务方签字确认。

4.2 Glue阶段的三大死亡陷阱与避坑指南

Glue是AI编程中最容易翻车的范式，因为它的失败往往悄无声息。以下是我在项目中总结的三大死亡陷阱：
陷阱一：混淆“语法胶水”与“语义胶水”。语法胶水（如JSON转XML）是程序员的事，AI插不上手；语义胶水（如“投诉”在客服系统指工单，在舆情系统指微博提及）才是AI的主战场。一旦让AI去处理纯语法转换，它会生成大量脆弱的正则表达式，稍有格式变化即崩溃。
陷阱二：忽略“语义漂移”。Glue规则不是一劳永逸的。某金融项目初期Glue规则定义“逾期”为“还款日+3天”，半年后风控策略升级为“还款日+1天”，但Glue层未同步更新，导致催收系统持续发送错误提醒。因此，Glue产出物必须包含“语义漂移检测机制”，例如在规则旁标注“此定义有效期至2024-Q3，到期前7天自动告警”。
陷阱三：缺失“人类仲裁点”。所有Glue规则必须设置明确的“无法判定”出口。例如：“当后台状态为‘制证’且APP状态为‘待受理’时，触发人工核查流程”。没有这个出口的Glue，就是埋雷。

提示：Glue阶段的验收标准，不是“代码跑通”，而是“业务方能用自己的语言解释每条规则”。如果业务方说“这条规则我看不懂”，说明Glue失败，必须重来。AI在这里的价值，是把业务语言翻译成可执行规则，再把规则翻译回业务语言供确认。

4.3 Glue规则生成器：用“三明治验证法”确保鲁棒性

为避免Glue规则成为黑箱，我设计了一套“三明治验证法”，强制在规则生成过程中嵌入三层校验：
第一层：正向注入。用AI生成100条符合规则的典型样本（如后台状态“收件”→APP状态“待受理”），交由业务方确认是否符合预期。
第二层：反向扰动。AI主动制造50条“边界模糊”样本（如后台状态“缴费”但支付渠道异常，APP应显示什么？），要求业务方现场决策，将决策结果反哺规则库。
第三层：负样本攻击。AI生成20条明显违反业务常识的错误映射（如后台“归档”→APP“受理中”），验证规则引擎能否100%拦截。

这套方法在某教育项目中暴露出关键问题：业务方认为“课程结束”状态应映射为APP“已完成”，但AI在反向扰动中发现，当课程因师资问题提前终止时，“课程结束”实际等同于“已取消”。这个发现直接催生了新的状态码。Glue不是缝合，而是通过AI的“刻意找茬”，逼出隐藏的业务规则。

5. Spec范式：当功能正确却总被退货，AI是你的“验收翻译器”

5.1 Spec的真相：在人类模糊语言和机器精确执行之间架设桥梁

Spec范式常被等同于“写单元测试”，这是致命误解。单元测试验证的是代码是否符合开发者自己的理解，而Spec验证的是代码是否符合业务方心中那个未曾言明的、活的、情境化的“正确”。某支付项目曾发生经典案例：开发团队实现的“退款到账时间”逻辑完全符合PRD文档——“T+1工作日内到账”。但上线后大量客诉，因为业务方实际意指“T+1日24:00前到账”，而开发理解为“T+1日任意时间”。PRD文档的模糊性，在Spec阶段才真正暴露。

Spec阶段的AI，核心任务是将业务方碎片化、情境化、带情绪的验收描述，转化为可穷举、可自动化、可追溯的机器可执行断言。例如，业务方说：“用户看到的余额要准，不能有延迟”。AI需将其拆解为：

• 准确性：余额显示值 = 账户表current_balance字段值（非缓存值）；
• 实时性：从账户表更新到前端显示，延迟 ≤ 500ms（P99）；
• 情境覆盖：涵盖充值、消费、退款、冻结、解冻所有资金变动场景；
• 异常兜底：当数据库延迟 > 500ms时，前端显示“余额更新中…”而非旧值。

这个过程，AI不是在写测试，而是在进行一场精密的“语义考古”，挖掘藏在日常用语下的精确契约。

5.2 Spec生成的黄金四象限：覆盖所有验收盲区

我将Spec生成过程划分为四个强制象限，任何遗漏都会导致验收返工：
象限一：正向黄金路径。覆盖80%常规场景，如“用户正常下单→支付成功→订单状态变更为‘已支付’”。这是最容易想到的，但必须用AI穷举所有合法输入组合（如不同支付方式、不同地址类型）。
象限二：负向边界撕裂。专门针对PRD中“不应发生”的情况，如“用户余额不足时尝试支付，系统应拒绝并返回明确错误码，而非扣款失败后仍显示‘支付中’”。AI需基于领域知识，生成所有可能触发边界条件的输入。
象限三：时序幽灵场景。处理多步骤间的竞态条件，如“用户A在订单支付中，用户B同时取消该订单，此时A的支付结果应为失败”。这类场景人类极难穷举，AI可通过状态机遍历自动生成。
象限四：感官欺骗陷阱。针对前端展示的“看起来正确实则错误”情形，如“优惠券列表按‘折扣力度’降序排列，但当力度相同时，应按‘剩余数量’升序，而非随机”。业务方往往只说“要好看”，AI需将其翻译为像素级的排序规则。

在某政务APP项目中，AI在象限四发现关键漏洞：业务方要求“办理进度条要直观”，AI生成的Spec指出“当进度为80%时，进度条视觉长度必须≥屏幕宽度的75%”，否则用户感知不到进展。这个细节从未出现在任何文档中，却直接影响用户满意度。

5.3 Spec执行监控：让验收从“一次性考试”变为“持续体检”

Spec的价值不仅在于生成，更在于执行。我坚持Spec必须具备“自我监控”能力：

• 可追溯性：每条Spec断言必须关联原始业务描述（如“源自2024-03-15需求评审会议纪要第3.2条”）；
• 可解释性：当Spec失败时，AI需生成人类可读的失败根因（如“失败原因：支付回调通知中order_id字段为空，而业务方明确要求此字段必填”）；
• 可演化性：Spec文件必须包含版本号和变更日志，每次PRD更新，AI自动比对差异并标记受影响的Spec条目。

某电商项目上线后，AI监控到“购物车删除商品”Spec的失败率在凌晨2点突增。自动分析发现，是第三方推送服务在该时段批量发送“商品下架”通知，触发了购物车清理逻辑，但通知中缺少必要字段。这个发现，让运维团队在业务方投诉前就修复了问题。Spec不是终点，而是系统健康的听诊器。

6. Smell范式：在代码合入前，AI是你的“第六感增强器”

6.1 Smell不是找Bug，是嗅出代码的“健康气息”

Smell范式常被当作“AI版Code Review”，这是对其价值的严重矮化。传统Code Review关注的是“是否符合规范”“是否有潜在Bug”，而Smell关注的是代码是否散发出与系统整体气质不符的“异味”——这种异味，往往是架构腐化、技术债累积、团队认知偏差的早期征兆。例如：

• 在一个以“高并发读”为设计核心的新闻APP后端，突然出现大量@Transactional注解，这是“事务蔓延”的Smell，暗示开发者可能在用关系型数据库思维解决缓存问题；
• 在一个强调“零信任”的安全系统中，某处API文档赫然写着“无需鉴权”，这是“信任透支”的Smell；
• 在一个追求“极致性能”的实时渲染引擎里，某函数内部调用了System.currentTimeMillis()做日志打点，这是“时钟污染”的Smell，暴露了对微秒级延迟的无知。

Smell不是错误，而是危险信号。AI在此阶段的任务，是充当一个不知疲倦的、拥有全系统上下文的“气味猎犬”，在海量代码中精准定位那些违背系统灵魂的异质片段。

6.2 Smell识别的五维光谱：超越语法的深度扫描

我将Smell识别建模为五维光谱分析，每一维对应一种系统健康维度，AI需在每个维度上进行强度扫描：
维度一：架构忠诚度。代码是否忠于系统宣称的架构风格？（如声明为“事件驱动”，却在关键路径使用阻塞式HTTP调用）
维度二：领域纯粹性。业务逻辑是否被技术细节污染？（如订单服务中出现Kafka配置参数）
维度三：演化友好度。代码是否便于未来修改？（如硬编码的魔法数字、缺乏扩展点的if-else链）
维度四：可观测性完备度。关键路径是否缺失必要的监控埋点？（如支付核心流程无成功率指标）
维度五：安全基线符合度。是否无意中绕过了既定安全控制？（如用字符串拼接构造SQL，即使当前参数已过滤）

在某金融风控项目中，AI在维度一发现严重Smell：系统架构图明确标注“实时决策流走Flink”，但实际代码中，70%的风控规则执行在Spring Boot的Controller层，Flink仅用于日志收集。这个Smell直接触发了架构重审，避免了后期百亿级数据量下的性能灾难。

6.3 Smell响应机制：从“报警”到“自愈”的闭环

Smell的价值不在发现，而在响应。我设计了一套Smell响应闭环，确保每个Smell都导向行动：

1. 分级告警：Smell按严重性分三级。Level 1（警示）：需在下次迭代修复（如“日志级别过低”）；Level 2（警告）：阻塞当前分支合入（如“核心API缺少熔断”）；Level 3（危急）：立即回滚（如“生产环境密钥硬编码”）。
2. 根因溯源：AI对每个Smell自动关联可能的根因（如“事务蔓延”Smell，AI提示“检查是否因缓存失效导致频繁DB查询”）。
3. 修复建议：提供可直接应用的修复方案（如“将@Transactional移至Service层，添加@Cacheable注解”）。
4. 预防植入：将Smell模式注入CI流水线，在代码提交时实时拦截同类问题。

某团队在引入Smell机制后，Level 2以上Smell数量在三个月内下降89%，更重要的是，团队开始自发讨论“我们的系统应该散发什么气味”，这种文化转变，比任何技术改进都深刻。

7. 五大范式协同作战：一个真实项目的全周期实战推演

7.1 项目背景：为社区医院构建“慢病随访助手”

为说明五大范式如何在真实项目中交织运作，我以某社区医院“慢病随访助手”项目为例。该项目目标是：让医生能通过语音快速录入高血压/糖尿病患者的随访记录，并自动生成结构化报告供家庭医生签约服务使用。表面看是个简单的ASR+文本生成，但实际贯穿了全部五个范式。

7.2 Vibe阶段：从“医生说不清”到“可验证的模糊点”

初始需求：“医生说话，系统记下来，生成报告”。Vibe阶段，AI生成追问清单：

• “医生口述时，是否会夹杂方言或医学缩写？（例：‘BP’‘HR’）” → 确认需支持本地化ASR模型；
• “生成的报告，是给医生自己看，还是上传至区域健康平台？” → 确认需符合《区域卫生信息互联互通标准化成熟度测评》文档格式；
• “当患者说‘最近头有点晕’，系统应记录为症状还是转诊建议？” → 确认业务规则：所有主观感受必须标记为“患者主诉”，不得自动转译为诊断。
  最终产出《已确认模糊点清单》，明确“报告必须保留原始语音时间戳”“不支持自动诊断建议”等硬约束。

7.3 Plan阶段：在资源受限下推演可行性

基于Vibe结论，Plan阶段聚焦：

• ASR准确率：本地化模型在方言场景下WER（词错误率）预计18.3%，是否可接受？（业务方确认：≤20%即可）；
• 报告生成延迟：从语音结束到报告生成，P95需≤3秒，否则医生体验断裂；
• 合规风险：语音数据存储需满足等保2.0三级要求，本地化部署成本是否可控？
  蒙特卡洛模拟显示，在现有服务器配置下，92%的请求能满足3秒延迟，但需增加SSD缓存层。Plan结论：可行，但需追加硬件预算。

7.4 Glue阶段：打通语音、文本、报告三座孤岛

系统涉及三个子系统：语音识别服务（Python）、临床术语标准化服务（Java）、报告生成服务（Go）。Glue阶段，AI构建语义中间层：

• 将ASR输出的原始文本，按医学本体库（SNOMED CT）映射为标准术语；
• 定义“血压”“血糖”等关键指标的单位统一规则（如ASR可能输出“mmHg”或“kPa”，必须强制转为“mmHg”）；
• 设计“无法标准化”术语的兜底策略（如患者说“心口疼”，映射为“胸痛（待确认）”并触发人工审核）。
  Glue规则经三方技术负责人签字确认，成为集成契约。

7.5 Spec阶段：让“生成报告”不再是一句空话

Spec阶段，将业务方模糊要求转化为可执行断言：

• 正向：当ASR识别出“血压140/90”，报告中“收缩压”字段值=140，“舒张压”字段值=90；
• 负向：当ASR识别出“血压正常”，报告中不得出现具体数值，而应标记为“未测量”；
• 时序：从语音停止到报告生成，必须在3秒内完成，超时则返回“处理中，请稍候”；
• 感官：报告PDF必须包含医院Logo和防伪水印，否则视为无效。
  所有Spec纳入自动化测试套件，每日构建时执行。

7.6 Smell阶段：守护系统健康底线

上线前Smell扫描发现：

• 架构忠诚度Smell：语音服务调用术语标准化服务时，使用了HTTP短连接，违背“高并发低延迟”架构宣言；
• 领域纯粹性Smell：报告生成模块中，混入了Kubernetes Pod健康检查代码；
• 安全基线Smell：语音上传接口未校验Content-Type，存在文件上传漏洞风险。
  所有Level 2以上Smell在合入前修复，系统上线后首月零P1故障。

8. 范式切换的临界点识别：一张图看清何时该换“工具”

8.1 临界点不是时间点，而是认知状态的跃迁

五大范式不是按项目阶段线性推进，而是根据团队当前的认知状态动态切换。识别切换临界点，比掌握范式本身更重要。我总结了一套“认知状态仪表盘”，当指针进入特定区域，即触发范式切换：

• Vibe→Plan临界点：当团队开始争论“应该用什么技术”而非“到底要解决什么问题”时；
• Plan→Glue临界点：当技术方案确定后，不同模块负责人开始互相质疑“你的接口定义不合理”时；
• Glue→Spec临界点：当胶水代码写完，但业务方第一次看到Demo时说“这不对，我要的不是这样”时；
• Spec→Smell临界点：当所有Spec测试通过，但资深工程师皱眉说“这段代码味道不对”时。

这个仪表盘没有技术参数，只有人类行为信号。它提醒我们：AI编程范式，终究是服务于人的认知协作。

8.2 范式误用的灾难性后果：三个血泪教训

范式误用比不用更危险，以下是真实发生的三个教训：
教训一：Vibe阶段混入Plan。某团队在需求模糊期，强行让AI对比LangChain和LlamaIndex。结果团队过早绑定技术路径，当Vibe后期确认需支持离线场景时，已投入的LangChain方案无法改造，项目延期两个月。
教训二：Plan阶段跳过Glue。某项目直接按Plan结论开发，忽略系统间语义差异。上线后发现，财务系统传来的“金额”是分，而订单系统期待元，导致所有账单错乱，紧急回滚。
教训三：Smell阶段替代Spec。某团队迷信AI Smell扫描，取消了Spec编写。结果上线后，AI未识别出“报告中患者姓名必须脱敏”的业务规则，因隐私泄露被监管处罚。

注意：没有银弹，只有适配。Vibe解决混沌，Plan管理不确定，Glue弥合语义，Spec锚定验收，Smell守护健康。用错范式，如同用手术刀切菜——不是刀不好，是拿错了场合。

9. 个人实战心得：那些文档里永远不会写的细节

9.1 关于AI的“人格设定”：让它成为团队一员，而非工具

我坚持在每个项目启动时，为AI设定明确的“角色人格”。不是“你是一个AI助手”，而是“你现在是本项目首席语义架构师，你的职责是暴露所有未言明的假设，你的KPI是让业务方签字确认每一条模糊点”。这个设定会显著改变AI的输出风格——它会更主动追问，更敢于指出矛盾，而不是迎合人类。当AI说“根据您之前确认的第3条，此处逻辑存在冲突”，它已经不是工具，而是协作者。

9.2 关于提示词的终极真相：最有效的提示词，是删掉所有修饰词

经过数百次实验，我发现最高效的提示词，往往最简陋。例如，Vibe阶段的提示词，我最终固化为：“请基于以下描述，列出5个最关键的、必须由业务方确认的模糊点。每个模糊点必须包含：1) 具体疑问；2) 此疑问未确认将导致的直接后果。不要解释，不要建议，只提问。” 所有形容词、副词、礼貌用语，都是干扰项。AI不需要被“温柔对待”，它需要被精准指令。

9.3 关于失败的唯一真理：所有失败，都源于范式错配

回顾所有失败项目，根源从来不是AI能力不足、模型不够大、算力不够强，而是范式错配。当团队在Vibe阶段就焦虑“怎么写Prompt”，在Plan阶段纠结“哪个模型更好”，在Smell阶段抱怨“AI找不到Bug”，其实都在同一个问题上打转：没搞清此刻最需要AI扮演什么角色。这五大范式，是我用时间和真金白银买来的认知地图。它不保证成功，但能让你在迷路时，至少知道地图上标着“此处有悬崖”，而不是在悬崖边继续狂奔。