现在的AI辅助开发已经不是我两年前刚接触时的那个样子了。从最初的自动补全、聊天问答到现在的vibe coding、AI Agent、还有像harness × sdd这种面向交付的工程方法整个生态几乎一年一个样。我身边不少朋友尝到甜头后第一反应都是“这玩意太爽了让AI把代码全写了就行”结果项目跑到一半代码库变成无人能解的“黑盒”前端能跑、后端报错、数据库迁移没人敢动、一改就崩最后只能推倒重来。这篇内容想聊的就是AI全栈开发这条路上的心得和方法论。我会从vibe coding的失控现场讲起聊到怎么用harness × sdd这套约束机制把AI的产出拉回工程正轨再落到工具链选型、端到端实操流程、常见问题排查适合正在做AI应用开发、或者想把AI编程真正落地到日常工作中的朋友。核心目标就一个让AI帮你写代码但代码库的命脉始终掌握在你自己手里。1. 从vibe coding到工程化为什么“顺着感觉写”会失控1.1 vibe coding是什么为什么人人都爱它vibe coding这个词火起来不是没道理的。它描述的是一种很“随性”的写码方式你把自己的想法用自然语言描述给AI比如“帮我写一个带登录注册的博客系统前端用React后端用FastAPI数据库用SQLite”然后AI噼里啪啦生成一堆代码你看着差不多能跑就提交、上线。这种方式的吸引力非常直接。第一写原型的效率高得离谱以前一个周末才能搭起来的小工具现在半小时就能出个能演示的版本。第二它把编程的门槛拉低了一大截哪怕不是科班出身只要能把需求和逻辑讲清楚也能“做出一款产品”。我自己在给团队做内部小工具的时候也会下意识先让AI铺一版底子再往里补细节。但问题恰恰藏在这种“爽感”里。vibe coding的本质是让AI替你决策而你只负责“感觉对了没”。短期看生成的速度确实快长期看你在逐步放弃对代码库的理解和掌控。我见过最典型的场景是一个人用AI两个小时生成了一套系统第二天想加个字段发现自己根本不知道应该改哪个文件只能继续让AI猜猜错了他也看不出来于是就在“AI改代码—我验收—改错—再让AI改”的循环里越陷越深。1.2 失控现场代码库变成“AI盲盒”如果你也这么干过下面的场景估计都能对上号。代码无法被review。AI生成的代码往往“很像是那么回事”但仔细看会发现很多莫名其妙的逻辑分支、冗余封装甚至它自己编造的一个根本不存在的第三方库调用。如果团队里没有人去逐行review这些代码就会带着隐患进入生产环境。依赖地狱。AI不会替你考虑依赖收敛它只会针对你当前的Prompt给出“最可能正确”的包。你今天让它加一个PDF解析功能它就装一个pypdf明天让它加一个表格读取它又装一个openpyxl。等依赖列表越来越长版本互相冲突整个工程直接进入不可维护状态。复现困难。vibe coding生成的项目常常缺少规范的构建脚本和配置管理依赖锁文件不完整、环境变量散落在文档里、数据库迁移脚本靠手写。换台机器、换个人接手项目就“跑不起来了”。还有更隐蔽的AI幻觉。它会在注释里一本正经地解释一个根本不存在的设计模式会在代码里调用一个“看起来很像真的”但实际不存在的API。这些错误单个看不太严重叠在一起就是一个大坑。1.3 工程化的解法给AI戴上“harness”用规范牵引所以我不太推荐一上来就“vibe coding一把梭”。更靠谱的路子是把AI嵌进一套工程约束体系里——这就是热词里那个harness × sdd 组合的实际意义。harness翻译过来是“鞍具”或“约束框架”。在AI开发的语境里它指的是你为AI设置的边界条件用什么语言和框架、项目目录怎么组织、依赖怎么管理、代码规范是什么、测试怎么跑、CI怎么卡。AI在这个边界内自由发挥边界之外由你把守。sdd全称是Spec-Driven Development翻译成“规格驱动开发”。它和传统的需求文档有相似之处但更强调“可验证”。一份好的Spec会写明背景、接口、行为、验收标准、边界条件AI照着Spec写代码你照着Spec验收。它的核心逻辑是让AI从“猜需求”变成“照图施工”。harness负责划定“不能干什么”sdd负责说清楚“要干什么”。两者叠在一起AI的产出就从“灵感乍现的草稿”变成了“可交付、可维护、可验收的代码”。我在后面会详细拆这套流程具体怎么落地。2. harness × sdd 方法论把AI编程从“玄学”变成“工程”2.1 Spec-Driven Development先写规格再见代码很多开发者对“写文档”有天然抵触觉得那是流程化的大公司才干的事。但在AI开发时代Spec不是写给领导看的而是写给AI看的“施工蓝图”。没有蓝图的AI写代码就像让一个实习生直接上手改生产环境他肯定很勤奋但结果你不敢保证。一份能指挥AI干活的Spec至少要有这么几个部分背景与目标这个功能解决什么问题用户是谁价值是什么。功能边界做什么、明确不做什么。接口定义API路径、请求参数、返回结构、错误码。行为规则核心逻辑的输入输出映射最好给出具体示例。验收标准可量化的通过条件比如“100条测试问题中准确率≥90%”。非功能要求性能、安全、可观测性等。举个例子我正在做一个企业知识库客服机器人第一版Spec里关于“知识库覆盖不到时怎么办”的约束是这么写的边界与兜底 - 当用户问题在知识库中没有匹配内容时系统必须返回“未找到相关资料”不得编造答案。 - 如果检索到的文档与问题相关性得分低于阈值如0.35同样按“未找到”处理。 - 返回结果必须附带引用来源方便用户核对。这段约束看起来简单但它直接砍掉了AI幻觉的最大来源——“硬答”。没有这条SpecAI很可能会基于自己训练时见过的知识编造一个看起来合理但根本不在企业知识库里的答案。这在线下Demo时没感觉上线被老板一问一个准。2.2 Harness怎么搭边界、依赖、规范、自动化一条龙Spec管“做什么”Harness管“在什么框架里做”。我搭Harness一般从四个方面入手。依赖锁定是第一步。每次AI生成完代码立刻检查有没有新增依赖、有没有改动依赖版本。Python项目必须提交requirements.txt或pyproject.toml的锁文件Node项目必须有package-lock.json。目的是保证两台机器上跑出来的依赖树完全一致不然今天你本地能跑明天部署环境就挂了。目录结构强制约定。AI生成代码时倾向于把逻辑全堆在一个文件里尤其那种“一条龙”生成的需求。我的做法是提前在项目根目录放一个README和AI规则文件比如Cursor里的.cursor/rules、Claude Code里的CLAUDE.md明确写清楚目录职责src/ # 业务代码 api/ # HTTP接口层 core/ # 核心业务逻辑 integrations/ # 外部服务对接 models/ # 数据模型与Schema tests/ # 测试目录与src结构一一对应 docs/ # 架构与Spec文档这样AI在新增代码时会倾向于往约定位置放而不是顺手在根目录建一个新目录。静态检查与格式化拉满。ESLint、Prettier、Ruff、Black、mypy这类工具以前是“团队规范”才配的现在是我做AI开发的标配。它们不是限制AI而是帮AI兜底AI生成代码用错了变量类型、忘了处理空值、格式乱了静态检查会直接报错把问题拦在代码评审之前。CI里强制跑测试。我不允许“AI生成完代码、我本地跑一下没问题就提交”这种流程存在。代码进主线前CI至少要做三件事lint检查、单元测试、构建验证。这块自动化起来以后AI代码的质量下限会被抬得很高。2.3 小步快跑的AI工作流一次只让AI干一件事有了Spec和Harness接下来的关键就是执行节奏。很多人在AI开发上翻车不是因为AI不行而是因为“一口吃个胖子”。我给AI派活的原则是单次任务要小到“15分钟到1小时就能验证完”。比如“实现用户登录的API接口接收用户名密码校验后返回token”是一个合适的任务“把整个商城系统写出来”是一个灾难。小任务至少有三个好处。第一任务越小AI的上下文负担越轻它越能专注于当前需求代码质量越高。第二验收简单每个小任务都有明确的测试和边界出了问题能快速定位。第三代码review压力小你可以在几分钟内看完diff发现问题立刻让AI修正不会积累成一个大黑盒。我常用的一个工作流模板是这样的1. 从Spec中挑出一个可交付的小任务。 2. 把任务、接口定义、验收标准一起发给AI。 3. 让AI先写测试或补测试说明再写实现。 4. 本地跑测试、跑lint通不过就带着报错信息让AI修。 5. 通过后人工看一遍diff确认没有问题再合并。这里有个小技巧与其让AI“直接写代码”不如先让它“列出实现计划和涉及文件”。这一步看似多余但实际上能把AI的思考路径显性化你可以在它动手前就纠正方向省掉后面一大段返工。2.4 一份可以直接抄的任务Prompt模板每次都要打一大段上下文确实麻烦。我的做法是把“任务派发格式”固定下来直接套模板既省时间又能保证AI不跑偏。【任务】 一句话说清楚要做什么 【背景】 贴相关Spec片段或需求链接 【约束】 - 只修改以下文件xxx - 不允许新增第三方依赖 - 遵循src/目录结构约定 - 必须补充对应的单元测试 【验收标准】 - 测试命令pytest tests/test_xxx.py - 通过条件全部通过 - 不允许出现xxx 【输出要求】 - 先给出实现方案简述再给出代码diff - 代码必须通过ruff检查和mypy类型检查这套模板我用了大半年最大的感受是AI非常吃“结构化指令”。你把约束写清楚它出错的概率会指数级下降你越是让它“自由发挥”它越是放飞自我。3. 工具链选型AI全栈开发的武器库3.1 AI编程工具从自动补全到Coding Agent现在的AI编程工具大致分两派一派是“辅助人类写代码”代表是GitHub Copilot、Cursor的Tab补全另一派是“代替人类写代码”代表是Claude Code、Aider、Cursor的Agent模式、Devinci这类Coding Agent。自动补全型工具适合“人在回路”的场景你已经知道要写什么但想让AI帮你快速把样板代码打出来。它们对你的项目上下文侵入小几乎是零成本接入。Coding Agent则完全不同它能自己阅读仓库、多文件修改、执行命令、跑测试、根据报错自动迭代效率和自动化程度直接拉满但风险也更高——它改代码的幅度大、涉及面广如果你没有测试兜底很容易“越帮越忙”。我个人的选择标准很简单任务大而边界清晰、且有CI保护的项目优先用Agent模式让它自己跑任务任务小而灵活、我还在探索阶段的用自动补全型工具自己动手更可控。从实际体验看Claude Code这类工具在“读大仓库、跨文件重构”上的能力已经比一年前强了不止一个档次强烈建议有经验的朋友在低风险分支上先试试。3.2 litellm proxy统一模型网关为什么值得自托管做AI全栈开发绕不开一个问题项目里到底该接哪个大模型。OpenAI、Anthropic、Google、国内的各家模型各有擅长价格也不一样。如果直接在业务代码里写死某个厂商的SDK后面想换模型、加fallback、管控成本都得改代码重新发版非常痛苦。litellm proxy就是解决这个问题的它把自己包装成一个OpenAI兼容接口的服务背后统一路由到各家模型。业务代码只需要面向一个“标准接入点”模型怎么调度、怎么切换、怎么降级全部在网关层配置。我现在的标准玩法是所有项目统一通过litellm proxy访问模型核心配置长这样model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/ANTHROPIC_API_KEY router_settings: fallbacks: - {gpt-4o: [claude-3-5-sonnet]} num_retries: 3 timeout: 30配置里做的事情是主模型gpt-4o挂了或者超时自动fallback到claude-3-5-sonnet重试3次。对业务代码来说它根本感知不到这些切换接口长什么样、调用体验就什么样。除了fallbacklitellm proxy还帮我解决了三个实际问题一是成本管控每个团队、每个项目可以用不同的API Key在网关层设置速率限制和预算上限再也不会出现某个服务偷偷烧掉一大笔钱的情况二是权限管理不用把各家模型的真实API Key下发到每个前端或后端服务只需暴露网关Key三是可观测性网关自带日志和用量统计每个请求用了哪个模型、耗时多少、Token消耗多少一目了然。如果你在做一个多Agent、多服务的AI产品我强烈建议把模型网关放到基础设施层来考虑。它不复杂但能省掉大量后续的“各处改模型调用代码”的麻烦。3.3 Agent编排框架什么时候用LangGraph什么时候不用说到AI Agent很多人的第一反应是“我是不是得用LangChain/LangGraph”。我的回答通常是先别急着上框架想清楚你的Agent到底有多复杂。简单场景比如“一个聊天机器人收到消息后检索知识库、调用一次大模型、返回答案”这种用FastAPI写个接口就行或者用Dify这类低代码平台拖一拖就能上线。引入一个重框架反而是用大炮打蚊子。复杂场景才值得上编排框架。比如你有多个Agent协作有状态流转、有条件分支、有循环执行还有人工审批节点这时候LangGraph这类“有状态图”框架的价值就出来了。它的核心抽象是Graph节点代表一个处理步骤边代表状态流转状态对象可以跨节点传递非常适合做“流程型”Agent。我自己在知识库客服机器人的Agent设计里就把流程拆成了五个节点router意图路由 - retrieval知识检索 - generation答案生成 - guardrail答案校验 - response结果返回用Graph表达之后每个节点都是一个独立的函数可以单独测试、单独替换、单独加日志。这比把全部逻辑塞进一个“prompt 一次模型调用”的脚本要清晰得多也方便后续把某个节点从“调大模型”升级成“调专用小模型”。选型的另一个关键点是团队能力。如果团队里没有熟悉Graph编排概念的人硬上LangGraph会让维护成本飙升。我的习惯是先拿一个不重要的功能试水跑通再推广不要一上来就把所有Agent都迁移进去。3.4 AI Infra必备可观测性、Prompt管理和评测AI全栈开发的基础设施和其他后端项目有个很大的不同你多了一层模型调用的不确定性。传统接口的输入输出是可预期的模型则可能今天答得好、明天换个版本就飘了。所以AI基础设施必须包含“可观测性、Prompt管理、离线评测”这三件套。可观测性我用的是Langfuse这类开源的Trace工具。每个模型的输入、输出、耗时、Token用量、自信心得分都记录在案。线上出了问题可以按用户ID、会话ID查链路快速定位是检索问题、模型问题还是提示词问题而不是靠用户截图“猜”问题。Prompt管理则解决“提示词像洒落地上的代码”的痛点。把Prompt当作代码一样管理有版本、有评审、有发布记录而不是散落在各种配置文件和数据库里。我习惯把每个场景的Prompt模板做成独立的markdown或jinja2模板文件纳入Git管理改动时走MR评审这比直接在代码里改字符串要可控得多。离线评测是很多人忽视的一块。模型服务上线前必须有一批“金标准”测试集用来跑回归。比如知识库机器人我会准备200条测试问题标注好标准答案或答案来源每次调整Prompt、换模型、改检索参数后都跑一遍准确率对比。没有这套评测你怎么知道自己“优化”效果是变好了还是变差了4. 端到端实操从需求到上线的AI全栈工作流4.1 需求澄清先写一份能指导AI的Spec很多AI项目死在第一步需求没想清楚就开干。为了让整个流程可以完整复现下面我用一个“企业知识库客服机器人”当例子完整走一遍我日常开发的流程。需求背景公司内部有大量制度文档、产品手册、FAQ散落在不同地方员工日常找资料效率低。希望做一个对话式问答入口让员工用自然语言提问系统从知识库中检索答案并返回同时给出引用来源。这个需求看起来简单但如果不把它写成SpecAI拿到手就会“自由发挥”它可能去调用一个自带的知识库可能不返回引用来源更可能在知识库里找不到答案时编造内容。所以第一版Spec我重点写了三块功能边界、API定义、验收标准。## 功能边界 - 支持单轮问答不含多轮上下文v1 - 答案必须来自知识库检索结果 - 无检索结果或相关性不足时回复“未找到相关资料” - 每条答案必须附引用来源列表 ## 接口定义 POST /api/chat 请求体 { message: 年假制度是什么, user_id: zhangsan } 响应体 { answer: 根据《员工休假管理办法》..., citations: [ {title: 员工休假管理办法, url: https://wiki.example.com/leave} ], confidence: 0.92 } 错误码400参数缺失、502模型服务异常注意这里我没有写任何技术实现细节没必要在Spec阶段约束技术栈。写清楚“输入、输出、边界、验收”就够了技术选型后面单独定。4.2 项目脚手架让AI一次性生成规范骨架有了Spec接下来就可以让AI搭骨架。我习惯的Prompt是“根据以下Spec在src目录下创建FastAPI项目骨架包含healthcheck接口、日志中间件、统一异常处理不允许新增第三方依赖之外的框架目录结构遵循docs/ARCHITECTURE.md里的约定。”这一步最关键的是“约束先行”。先把目录结构、架构约定、依赖范围告诉AI它生成的骨架才是“干净”的。AI生成完骨架后我做的第一件事不是运行而是检查文件树、检查依赖声明、检查入口文件然后跑一遍lint和测试确保基础没歪。骨架确定后再逐个推进子任务先做知识库文档解析模块再做向量检索模块再接模型调用模块最后串成Agent流程。每个子任务都严格走“小步快跑”流程发任务、写测试、跑测试、人工review。看起来节奏慢但整个过程非常稳从来不会出现“第一天很爽、第二天救火”的情况。4.3 RAG接入与Agent编排核心环节的实现知识库问答的核心链路是RAG也就是“检索增强生成”。一句话解释用户问题先拿去检索相关资料把资料拼进Prompt再让大模型基于资料生成回答。这么做的好处是答案有据可依知识可以随时更新不需要反复微调模型。我在代码里会让AI先生成一个retriever模块核心是向量检索。具体流程是文档加载后切片每个切片用Embedding模型转成向量存入向量数据库我常用的是pgvector或Qdrant。用户提问时把问题转成向量查询相近的top-k个切片作为上下文。用LangGraph表达Agent流程的话核心代码结构大致是这样from langgraph.graph import StateGraph class AgentState(TypedDict): question: str docs: list answer: str citations: list confidence: float def retrieve(state: AgentState) - AgentState: state[docs] vector_store.search(state[question], top_k5) return state def generate(state: AgentState) - AgentState: prompt build_prompt(state[question], state[docs]) state[answer], state[citations] llm.chat(prompt) return state def guardrail(state: AgentState) - AgentState: if state[confidence] 0.35: state[answer] 未找到相关资料 state[citations] [] return state graph StateGraph(AgentState) graph.add_node(retrieve, retrieve) graph.add_node(generate, generate) graph.add_node(guardrail, guardrail) graph.add_edge(retrieve, generate) graph.add_edge(generate, guardrail)护城河在guardrail节点。很多RAG项目“召回得不怎么样”但还在硬答就是因为少了这层校验。我的做法是除了让模型返回答案之外还让它返回一个“答案来源于哪篇文档”的映射和置信度分数低于阈值就拒绝回答。这个规则看起来保守但它保住了“企业知识库机器人”最核心的价值——可信。4.4 测试与CI让AI先写测试再写实现做AI开发测试不是“可选增强”而是“安全气囊”。没有测试你根本不敢让AI大改代码有了测试你就可以放心大胆地迭代。我的习惯是让AI实现任何一个功能前先让它把测试清单列出来甚至直接写测试。比如做POST /api/chat接口我会要求AI先写这样几个用例- 正常流程传入合法问题返回答案和引用 - 兜底流程知识库无匹配内容返回“未找到相关资料” - 参数校验缺少message字段返回400 - 异常兜底模型服务超时返回502不泄露内部错误测试先行有一个非常实在的效果它逼着AI把“边界条件”想清楚而不是只写“happy path”。等测试写好了再让它去填充实现因为测试是“唯一正确的验收定义”AI的实现质量会明显高一个档次。CI这块我是在GitLab/GitHub Actions里配了三条流水线静态检查、单元测试、构建镜像。任何分支想合并到main三条必须全绿。这已经是现代工程团队的标配了但在AI开发里它的意义更大因为你在频繁地让AI改代码没有自动化的“守门员”代码质量根本守不住。4.5 部署与网关上线前最后一道关卡开发和部署之间AI项目比传统项目多了一道“模型接入”的关卡。如果业务代码直连各家模型SDK上线后会遇到一堆问题模型限流、各种厂商API兼容差异、密钥管理混乱。所以我在部署环节一定把litellm proxy作为独立服务先起起来。部署拓扑大致是客户端/前端 - 业务APIFastAPI - litellm proxy - 各家模型服务 - 向量数据库 - 日志/监控系统litellm proxy可以独立用Docker部署配置里挂上各家模型的API Key和路由策略。业务API里只存一个环境变量LITELLM_BASE_URL指向网关地址模型相关的一切策略改动都发生在网关层业务服务不感知。密钥管理我强烈建议不要硬编码在代码里也不要写进镜像。用环境变量注入或密钥管理服务本地开发用.env文件CI/CD里从机密变量注入。模型API Key如果泄露不仅会被盗刷还可能导致合规问题。部署完成后还有一件事要立刻做接监控告警。至少盯三个指标请求成功率、平均响应时间、Token消耗成本。模型服务的异常往往来得猝不及防没有告警线上用户就会成为你的“测试员”。5. 常见问题与排查技巧实录5.1 AI幻觉答非所问怎么防AI幻觉是RAG类应用的头号敌人。它的典型表现是知识库里明明没有相关内容模型却“自信满满”地编了一个答案语气还特别笃定用户根本分辨不出来。排查思路分三层。第一层先看检索召回是不是知识库本身没切片好、Embedding模型不合适导致该召回的资料没召回来。第二层看Prompt约束是否明确写了“只基于以下资料回答资料无相关内容时回复未找到”。第三层加置信度校验这也是我之前说的guardrail节点答案相关度不够就拒绝回答。我踩过的坑是把“提示词约束”当成唯一的防线结果换了模型版本之后约束失效了。后来上了“置信度阈值证据映射”这种机制化方案才真正把幻觉压下来。我的经验是能靠机制解决的问题不要只靠提示词。5.2 上下文窗口溢出AI改着改着就“失忆”了AI编程工具还有一个常见问题项目一大它就读不进整个仓库或者读着读着就忘了前面的要求开始胡乱修改无关文件。这个问题我现在用三个办法规避。第一严格控制单次任务的粒度小任务对上下文的依赖就小。第二用Agent模式时明确给它“只需要读取哪些文件、修改哪些文件”的清单其他文件不允许动。第三把长时间运行的Agent任务拆成多个阶段每个阶段重新加载上下文并在阶段衔接处把“已完成事项、下一步目标、验收标准”写清楚。还有一个小技巧如果AI生成的代码里反复出现“疑似前后不一致”的情况大概率是上下文太长了这时候不要硬扛停一下重新开一个新会话把最新的上下文和需求重新贴进去效果往往更好。5.3 AI改坏了已有功能回归测试是唯一救星“AI加新功能的时候把旧功能改坏了”是很多团队放弃AI开发的最后一根稻草。我自己也经历过让AI重构一个工具函数结果它顺手把调用方的参数顺序也改了所有相关测试全挂排查花了半天。事后总结根因就一个没有回归测试兜底。如果项目里有一套覆盖核心链路的测试AI改坏代码的瞬间测试就会报错AI自己就能根据报错信息修正根本不用你上手排查。所以我现在对新项目的要求是“测试先行”对老项目的要求是“先把核心路径的测试补上再引入AI改码”。另外人工review diff的习惯一定要养成。AI生成的代码合并前一定要肉眼过一遍不需要逐行看但要看“它改了哪些文件、动了什么逻辑、有没有顺带删掉看起来无关的东西”。这个习惯能拦住80%的隐性回归。5.4 模型接口不稳定网关fallback怎么配都不够稳做AI应用模型服务不稳定是家常便饭。限流、超时、接口报错哪个厂商都难免。你要是没有容错机制线上体验就是“答非所问外加时不时崩一下”。litellm proxy的fallback配置能解决大部分问题。做法是给每个“逻辑模型”配一到两个备用物理模型主模型失败自动切备胎。这里有个细节不要把fallback配成“用户重新请求一次”而是要在网关层自动做用户无感知。另外重试策略要用“指数退避”不然高峰期所有请求同时重试会把模型服务打得更死。如果业务对延迟极其敏感我还会在业务层加一层“本地兜底”缓存同样的用户问题在短时间内重复出现直接返回缓存结果不重复调用模型。这既省了成本又提高了稳定性。5.5 常见问题速查表现象可能原因快速解法AI生成代码风格混乱缺少规则文件和静态检查配置AI规则文件强制跑lint/format模型答出知识库外内容检索召回差或Prompt约束弱优化切片、加置信度阈值、加兜底规则Agent改到无关文件上下文溢出或指令模糊明确只允许修改的文件清单缩小任务粒度模型服务频繁超时厂商限流或配置不合理网关层配指数退避重试和fallback项目换机器跑不起来缺少锁文件/环境变量混乱提交依赖锁文件环境变量走.env模板线上出错难排查缺少Trace和日志接入Langfuse记录模型输入输出与Token用量最后想说两句做了大半年AI全栈开发我最深的体会是AI并没有颠覆软件工程的基本规律反而把那些“看起来可以省略”的工程纪律的重要性放大了无数倍。以前你可以靠记忆和熟练度去掩盖写文档、写测试、做Review的懒惰现在面对一个无限耐心、无限高效、但也可能无限离谱的AI同事你唯一的庇护就是流程本身。如果你现在正准备做一个AI相关项目或者正在被vibe coding的失控局面折磨我的建议是别急着上更炫酷的Agent框架先把Spec机制、Harness约束、测试兜底这三件事做扎实。这三样东西花不了多少时间但它们决定了AI是你的增强器还是你的掘墓人。最后再分享一个小技巧每周挑一个让你最头疼的模块试着用AI在同一需求下生成三版不同的实现然后逐个review。这个动作看起来费时间但实际上特别练“代码判断力”——看多了AI的“措辞变体”之后你反而更容易发现代码里真正的坏味道。这套玩法值得你试试。