请各位佬友来点评。准备在公司做一次技术分享，聊聊我的“上下文工程”实践

还有一版，佬友们看看哪个更适合用作分享。

自我感觉这一版有点术语过多，感觉不太适合初学者接触

建议把内容结合日常工作场景改成大白话来描述上下文工程在实际业务场景中的实践会比较好。

总感觉你像是讲了什么，又好像没讲什么~~ 哈哈

需要通俗易懂，并结合日常开发（或正在进行的项目）为例进行演示；

先按你的理解列核心点，在通过日常案例去演示讲解。

给我的第一感觉，很像是我直接问ai，ai给我的那种内容，个人感觉很空

没人发现佬的疯狂星期四 v50嘛

倒是也有一版，比较早期的，但是太草根了 ^-^

肯定有人觉得用 AI 写代码就是打开对话框输入需求，等它生成完直接复制粘贴。但在我们最近主导的“电商大促动态结算系统”重构项目中，如果直接把复杂的满减规则丢给大模型，它生成的代码根本没法上线。真正的核心在于“上下文工程”，也就是你怎么把业务背景、数据结构和限制条件精准地喂给它，控制它的输出质量。

德系工程里讲究严谨，这在 AI 辅助开发中同样适用。在启动这个结算项目时，我没有急着让 AI 写逻辑，而是先花时间写了一份详尽的 .cursorrules 规则文件。我把公司的财务对账规范、金额计算必须使用 BigDecimal 的强制要求，以及禁止在核心链路引入外部 HTTP 请求等约束，全部作为系统级上下文固化下来，从源头减少大模型的幻觉。

基于这些规则，我们采用了“接口驱动”的开发模式。对于核心的算价引擎，我手动定义了清晰的输入输出接口和状态机流转图。把大模型限制在实现具体接口的“沙盒”里，而不是让它去决定整个类的结构。这样即使它内部实现得不够优雅，也不会破坏系统的整体架构，避免了代码腐化。

疯狂堆砌业务逻辑是 AI 最容易犯的毛病。在开发“跨店满减叠加逻辑”时，AI 一开始生成了上百行的嵌套 if-else。因为我们在上下文里提前注入了公司常用的“策略模式”和“责任链模式”的代码示例，我直接告诉它：“参考上下文中的设计模式重构这段逻辑”。它很快就给出了符合规范的、易于后期扩展的代码结构。

狂奔的业务迭代离不开可靠的测试。对于这种涉及资金的系统，传统的单元测试编写成本太高。我们引入了基于属性的测试（Property-based Testing），让 AI 根据业务约束自动生成成千上万组随机边界数据进行模糊测试。只要这些测试用例全部通过，我们就有底气说这段算价逻辑在极端情况下也是健壮的。

星型拓扑的任务拆分是我们应对复杂系统的方法。结算系统涉及订单、库存、营销等多个域。我们没有让一个 AI 从头写到尾，而是将需求拆解为多个原子任务。每个任务只传递必要的上下文，避免了长文本导致的“注意力丢失”问题，也让后续的人工代码审查变得更加聚焦。

期间我们也踩过一些坑，最典型的就是 AI 喜欢自作主张引入新的第三方库来简化它的代码。为了解决这个问题，我们在 CI/CD 流水线中加入了严格的依赖审查。任何构建配置文件的变更，都会触发一个专门的审查脚本，只有白名单内的依赖才能被合并到主干分支，防止依赖污染。

四个维度的质量防护网是我们敢把 AI 代码合入主干的底气。这四个维度包括：静态代码扫描拦截低级错误、强类型检查保证数据结构安全、自动化集成测试验证业务闭环，以及最后的人工 Code Review 把关核心逻辑。机器负责广度，人类负责深度。

唯有建立完整的验证闭环，才能真正提高研发效能。在这个项目中，我们搭建了完整的端到端（E2E）测试环境。每次 AI 提交代码，系统会自动运行一套包含几十种典型用户下单场景的回归测试。我们不再逐行去抠 AI 写的每一行代码，而是重点看测试报告和系统的最终行为是否符合预期。

我们团队在这个项目后，开发心智发生了明显的转变。大家不再把自己定位为纯粹的“代码编写者”，而是“系统约束的定义者”和“业务逻辑的审查者”。把繁琐的语法实现交给 AI，把精力集中在业务边界的划分和异常场景的兜底上。

五步标准流程是我们沉淀下来的最佳实践：第一步梳理业务约束并写入规则文件；第二步定义核心接口与数据结构；第三步拆解任务并注入精准上下文；第四步运行自动化测试与静态扫描；第五步进行人工审查与合并。这套流程让新加入的同事也能快速上手 AI 辅助开发。

十分明确地说，上下文工程不是为了淘汰开发者，而是为了解放我们的生产力。当基础的编码工作被 AI 接管，我们才有时间去思考更深层的系统架构和业务价值。掌握了这套方法，你会发现应对复杂业务需求变得更加从容。

诚恳地说，感觉有点掉书袋，同时 insights不是很多，作为分享，那就完全看佬的目的是什么了。想体现自己技术好，那完全可以这么讲；如果是带兄弟，那肯定不行，这根本讲不明白，一句话听者能问3个问题。

还有 “上下文工程不是为了淘汰开发者，而是为了解放我们的生产力。” 这种没有信息的AI话

不过看到图2的藏头就释怀了

佬啊,我一行一行的看完了,打算说说看法 ^-^想着结合日常的开发任务,然后怎么拆解需求,提一提小小的建议,然后我就看到了第二版 ^-^ ^-^ 在哈雷佬那里看完圣经,又来这里看心得,不v我50说不过去了o

你看看第三版（原版）吧，那是真情流露的 ^-^

还是我太单纯了,这个险恶的周四 ^-^

你这个是准备口述出来的吗 还是准备做成一个文档会议分享呢？大概内容我看懂了 但是有些地方感觉有点虚了，用的名词太多，而且感觉解决的过于完美的感觉，可能我没有测试过哈

如果我整篇体验下来 我有几个问题比如

因为我们在上下文里提前注入了公司常用的“策略模式”和“责任链模式”的代码示例，我直接告诉它：“参考上下文中的设计模式重构这段逻辑”。它很快就给出了符合规范的、易于后期扩展的代码结构。

如果 ai 过度设计了怎么办呢？是怎么防止 ai 针对代码架构过度设计的问题呢？特别是使用上设计模式之后。

然后这里写

以及最后的人工 Code Review 把关核心逻辑。机器负责广度，人类负责深度。

但是我看你又说了

我们不再逐行去抠 AI 写的每一行代码，而是重点看测试报告和系统的最终行为是否符合预期。

那到底人为需要把控那些部分呢？ 到底是需要 codeview 还是不需要只看结果呢？我有点懵。

然后是这里

我们引入了基于属性的测试（Property-based Testing），让 AI 根据业务约束自动生成成千上万组随机边界数据进行模糊测试。

可能我技术不够 没体验过这个 但是我简单 搜了下这个 感觉有点过度复杂设计的感觉。

感觉增加了测试的成本。当然不是说多方面测试不好，只不过需要针对业务场景综合分析下性价比方案。

其他的 如果我是领导的话 我没看到数据支撑，也就是说你这一套架构工程 对项目的提升数据量化结果有吗？ 这套工程投入之前和之后的明显对比 有降本增效的效果吗 量化数据好像没有 如果我是领导 我不能直观确定是增效还是增本了 ^-^

其他的写的不错 对我也有一定的启发，感谢大佬。

特别适合在今天这个特殊日子开分享会是吧 ^-^