★ FEATURED ARTICLE 这是一篇系列文章上篇讲业务、版本、架构中篇讲安全与隐式耦合下篇讲协作与一致性。引言用 Trae 写代码、补全、解释、生成样板确实能省不少事。但它有个规律在“看起来会做”的事情上往往恰好做不对。“能跑”和“能进生产”之间隔着三道坎业务理解、版本依赖、架构判断。本文用三个可复现的案例讲清这三类坑并给出可直接套用的 Prompt 模板。一句话总原则先放这儿Trae 负责起草你负责判断、验证、承担。场景一业务理解——被“优化”坏的退款逻辑给 Trae 的 Prompt 很简单优化这段退款计算逻辑让它更简洁。它给出的版本defcalc_refund(paid,coupon):returnpaid-coupon代码确实更短了。但它不认识业务里的三条隐含规则退款金额不能超过实付金额优惠券要按比例分摊不能直接整张扣部分退款后剩余可退额度要保留代码“更优雅”了业务“更错误”了。线上紧接着出现退超和优惠券分摊错误。根因业务约束不在代码里在需求文档、在数据库、在老员工脑子里。Trae 读不到。改进方法把业务约束显式写进 Prompt让它“在约束内改”涉及金额、状态、权限的改动产出必须过业务方确认复杂业务先让它用自然语言复述需求确认理解对了再让它写可复用 Prompt【业务约束】 - 退款金额不得超过实付金额 - 优惠券分摊 - 部分退款后剩余可退金额需保留 【任务】 在不违反上述约束的前提下优化以下代码 粘贴代码场景二版本依赖——LangChain 的旧 API让 Trae 写一个“加载本地文档并建向量库”的示例它生成fromlangchain.vectorstoresimportChromafromlangchain.embeddingsimportOpenAIEmbeddings在 LangChain 0.2 之后这些导入路径已迁移直接报ModuleNotFoundError: No module named langchain.vectorstores根因模型训练数据有截止时间快速迭代的框架它记的是上一代写法。LangChain 这类 0.2 到 1.x 大改的框架尤其严重。改进方法Prompt 里写死版本号用 LangChain 0.3 的 API生成后先确认本地版本pip show langchain对照官方迁移文档跑通再提交建立“AI 生成后必跑一遍”的习惯别信“看起来对”可复用 Prompt使用 框架名 确切版本 的官方 API 编写。 不要使用任何已废弃的导入路径与参数。 如该版本 API 有变更按新版本写并注明版本号。场景三架构判断——“教科书式”的拆分方案问 Trae这个 5 万行的单体项目怎么拆微服务它给出一套“按领域拆分”的标准方案看着很权威。但它不知道你们没有容器化环境、团队只有 3 个人、并发其实只有几十。根因架构不是“理论上怎么对”而是“在你的团队和规模下怎么活”。它只知道通用答案。改进方法要方案不要结论让它列多个方案的利弊决策权留给人把团队约束告诉它人数、部署环境、数据规模、后续迭代方向架构决策落成 ADR架构决策记录AI 只当参谋可复用 Prompt【当前约束】 - 团队 3 人 / 无 K8s / 日活几十 / 无专职运维 【任务】 给出 3 种拆分方案每种列出收益、成本、对团队的要求、失败风险。 不要直接给结论。小结场景Trae 能做Trae 不能做你要补的一步业务逻辑起草保证业务正确约束写进 Prompt 业务方确认依赖/API起草保证版本对确认版本 跑通架构提供方案替你决策多方案对比 ADR下篇预告下一篇讲更危险的AI 写的上传接口我一眼看出三个漏洞——路径穿越、类型伪造、内存 DoS 全部可复现。另外还有一个更隐蔽的坑跨文件改动为什么总漏。关注追更系列不迷路。
阅读完成 · 觉得有帮助？
