职贝云数AI新零售门户

标题: AI编程的最大误区:我们在晋级模型,而他们在晋级环境 [打印本页]

作者: Qy0qF 时间: 昨天 19:48
标题: AI编程的最大误区:我们在晋级模型,而他们在晋级环境
读完这篇，企业IT程序员能把"先立规矩再用AI"的反直觉逻辑说清楚，并能起草一份驾驭AI生成代码的架构约束清单，而不需求等待公司搞大规模AI转型试点。

一、这个实验，颠覆了我对AI编程的一切假设

2025年8月，OpenAI外部一支只要3人的工程团队，做了一个近乎疯狂的决议。
他们规定：从第一行代码末尾，不手写任何一行代码。
5个月后，他们交付了一个被数百名OpenAI外部员工每天运用的软件产品。代码仓库里有大约100万行代码，覆盖范围包括：运用逻辑、测试、CI配置、文档、可观测性工具，以及一切外部开发工具。

而且，他们估计完成这一切所花的工夫，只要手写代码方式的非常之一。（来源：OpenAI Harness Engineering Blog）

这不是PPT里的数字。这是该团队工程师Ryan Lopopolo在2026年3月发布的工程博客中，亲身记录上去的数据。当这支团队后来扩展到7人时，更令人困惑的事情出现了：

平均每位工程师每天合并3.5个Pull Request——而且随着团队规模扩展，这个吞吐量非但没有下降，反而还在增长。（来源：OpenAI Harness Engineering Blog）

先停在这里想一秒：在你的团队里，每人每天产出多少个有意义的PR？这篇文章，是我读完这篇工程博客后，从其中提炼出来的10个反直觉发现。有些结论，和大多数企业程序员的直觉完全相反。

二、工程师的角色，被彻底重新定义了

很多人读到下面的数字会想：这证明AI才能有多强。其实，核心变量是工程师的工作方式变了。反直觉法则一：这支团队最重要的转变是：工程师的次要工作不再是写代码，而是设计"让AI能写好代码的环境"。

他们发现，早期停顿慢不是由于AI才能不足，而是由于环境还没预备好——AI短少必要的工具、笼统层和外部结构。他们的解法叫"深度优先工作法"：

把大目的分解成小的构建单元（设计、编码、评审、测试等），让AI逐渐构建这些单元，再用这些单元去解锁更复杂的义务。

反直觉法则二：当某件事失败时，解法几乎从来都不是"再试一次"——而是先找到缺失的才能，把它变成AI可以了解和执行的方式。

这句话非常值得反复读："解法几乎从来都不是'再试一次'。"InfoQ 2025年终AI Coding清点的一篇文章，从国内视角印证了异样的规律：AI agent宁愿从零末尾完成功能，也不复用已有库——由于对模型来说，"本人写一个能跑的版本"风险最低。处理这个成绩，不是换更好的模型，而是建立"必须复用已有模块"的架构约束。❓成绩：为什么异样的AI工具，不同团队产出差距那么大？💡概念：AI的输入质量，由运转环境的质量决议，不只由模型才能决议🔧操作：把"AI为什么生成了这段蹩脚的代码？"改成"环境里短少什么让AI走偏了？"✅验证：下次你在修AI生成的bug时，停上去问：这个成绩能不能经过加一条Lint规则来预防？

三、你那套"烦人"的架构规范，才是AI的真正燃料

这是整篇文章最重要的反直觉结论。
大多数企业程序员的天分是：严厉的架构规范会拖慢AI工具的引入速度。
这个天分是错的。反直觉法则三："文档约束不足以保证一个完全由AI生成的代码库保持内聚性。经过强迫执行不变量（invariants），而不是微观管理完成细节，我们让AI可以疾速交付，同时不会腐蚀架构基础。"

接上去这句，更颠覆：反直觉法则四："这是那种通常要等到有了数百名工程师才会思索的架构。但在有了coding agent之后，它是最早期的前提条件。约束，才是让速度和架构波动性并存的根本缘由。"

以前，架构规范是"当前再说"的事。如今不行了。有了AI，混乱的代码库会被以10倍速度复制成10倍混乱的代码库。他们的详细做法：为每个业务域定义固定的代码层次（Types → Config → Repo → Service → Runtime → UI），用自定义Linter强迫执行依赖方向写的是"不变量"，不是"完成规范"——比如"每条日志必须携带预定义的必填字段集合（如trace_id、service、severity），由 schema 静态校验。"，而不是"日志要用log4j"Linter的报错信息被专门设计成对AI可读的修复指引，让AI看到报错就知道下一步如何改他们还明白了边界感：反直觉法则五："你们深度关怀边界、正确性和可复现性。在这些边界之内，允许团队（或agent）在表达处理方案时有相当大的自在度。"

不规定AI用哪个库，但规定它不能跨越哪些层次边界。这和VentureBeat报道的EY案例高度吻合：EY开发团队将AI agent接入外部工程规范和合规框架后，完成了4-5倍的编程效率提升。脱离规范的agent，只能产出需求大量返工的通用代码。架构约束是约束AI的"笼子"？不，它是AI的导航系统。

四、AGENTS.md：它是目录，不是百科全书

这是另一个踩坑后才知道的反直觉发现。他们一末尾也尝试过"一个大AGENTS.md"方案——把一切规范都写出来。失败了。失败缘由有四：
上下文是稀缺资源
：一个宏大的指令文件会挤占义务本身、代码和相关文档的空间
当一切事情都"重要"时，什么都不重要
：agent会部分形式婚配，而不是全局导航
文档即刻末尾腐烂
：agent分不清什么还有效，人也懒得维护，整个文件变成"吸引人的费事"
单一文件无法做机械化校验
：无法验证覆盖率、新颖度、交叉链接反直觉法则六："所以我们不把AGENTS.md当百科全书，而是当目录（table of contents）。"

详细的结构：AGENTS.md大约100行，只充当指向其他知识源的地图；真正的知识库在结构化的docs/目录里，包含设计文档、执行计划、产品规格等。这背后有一个更深的准绳：反直觉法则七："从agent的角度来看，任何它在运转时无法访问的信息，实践上等于不存在。"

这句话对企业IT程序员尤其刺耳——由于你们积累了十年的系统知识，散落在Confluence、邮件链、群聊记录和老员工的脑子里。对AI代理来说，这些知识全部等于不存在。那次Slack上对齐了架构决策的讨论？没有写进代码仓库，对AI来说就跟不存在一样——就像三个月后新入职的工程师永远不会知道那次讨论一样。❓成绩：为什么AI总是"不了解"你们系统的特定规则？💡概念：AI只能运用它在上下文窗口里看见的信息；看不见的等于不存在🔧操作：打开AGENTS.md，删掉超过20%的内容（那些移到docs/目录），把剩余部分改成"指向其他文档的导航地图"✅验证：一个新入职的工程师看了AGENTS.md，能在3分钟内找到任何他需求的文档吗？

五、瓶颈迁移了：从"写代码"变成了"QA处理量"

随着AI代码吞吐量添加，这支团队遇到了一个完全预料之外的新瓶颈。反直觉法则八："随着代码吞吐量的添加，我们的瓶颈变成了人工QA处理量。"

这个转变意味着：当AI产出速度远超人类消化速度，人力工夫和留意力成为全新的稀缺资源。他们的解法不是招更多测试人员，而是把QA这件事也变成AI能做的事：让app可以按git worktree各自独立启动，AI能为每个变更运转独立实例把Chrome DevTools Protocol接入agent运转时，让AI能本人驱动阅读器做UI验证将日志、目的、链路追踪全部暴露给本地可观测性技术栈，让AI能用LogQL和PromQL查询本人代码的运转形态他们还分享了一个看起来离经叛道的发现：反直觉法则九："在某些状况下，让agent重新完成一部分功能，比费力调用某个公共库的不透明行为，成本更低。"

企业程序员的天分是"反复造轮子！"。但在AI编程环境下，逻辑不同了：让AI能残缺了解、验证和修正的代码，比依赖一个对AI不透明的外部依赖更有价值。他们的例子：用自完成的map-with-concurrency helper交换p-limit这类第三方包，由于自完成版本完选集成了OpenTelemetry追踪，有100%的测试覆盖，行为完全符合运转时预期。

六、重新定义研发节拍：修反比等待更便宜

最后一个反直觉的转变，是关于研发流程的节拍。反直觉法则十："代码仓库以最少的阻塞性合并门控运转。Pull Request是短暂的。测试偶发失败通常用后续运转来处理，而不是有限期阻塞进度。在一个agent吞吐量远超人工留意力的系统里，修正是廉价的，等待是昂贵的。"

这和传统企业IT的PR流程完全相反——通常是：代码评审 → 测试评审 → 安全评审 → 合并，每一环都能够等上几天。当AI能持续以每人每天3.5个PR的速度产出，阻塞性流程的成本会急剧放大。他们的做法是：将大部分评审工作交给agent-to-agent处理，只在需求人类判别时才晋级到人工审核。人类担任设定优先级、把用户反馈翻译成验收标准、验证最终结果。他们还建立了定期运转的"文档园丁agent"——持续扫描过时或不再反映真实代码行为的文档，自动开PR修复。技术债就像高息贷款：持续分批偿还，远比积累后集中爆破代价更低。

七、给企业IT程序员的三个明天就能做的动作

读到这里，你能够在想：这些是OpenAI精英团队在全新项目上做的实验，跟我的业务场景有什么关系？关系是：这些反直觉法则，在企业IT场景下反而更容易落地——由于你曾经拥有"架构约束"这一核心原材料。Stack Overflow在2026年3月的一篇博文里说了一件风趣的事：在引入AI coding agent时，"拥有成熟代码规范的企业，具有分明的先发优势"。你们那套有时分让人觉得"烦人"的架构规范、代码审查标准、命名商定——这正是AI代理需求的导航系统。你不需求从零末尾，你只需求把已有的规范"执行化"。
三个明天就能末尾的动作：
把现有规范变成可执行的Lint规则：找出团队规范文档中最重要的3条准绳，把它们转化为Linter规则（可以让AI帮你写），让规则在CI里强迫执行，而不是靠人工记忆。重写AGENTS.md（或等效文件）：不超过100行，只写"这里有什么、去哪里找"，删掉一切详细的完成指引（那些放到docs/目录）。定义一个"不可跨越的边界"：选一个最重要的架构约束（比如"制止Service层直接调用数据库，而用Repository 层独占数据库访问权"），写一个架构测试来验证它，然后让AI去维护这个测试。

写在最后：纪律迁移了，没有消逝

Harness团队的实验揭示了一个比"AI能写代码"更深层的道理：
软件工程的纪律没有消逝，它只是迁移了——从代码本身，迁移到了为AI生成代码服务的脚手架里。
以前，这个纪律体如今一行一行优雅的代码里。如今，它体如今架构约束、知识库结构和反馈闭环的设计里。工具变了，但工程师最核心的工作没有变：让复杂系统在约束内，牢靠地运转。你的架构规范，不是AI的绊脚石。它是AI的燃料。

假如你也在用AI coding工具，欢迎在评论区聊聊你们团队目后面临的最大应战：是AI生成的代码质量不波动？团队规范难以落地？还是曾经踩过某些你情愿分享的坑？

参考材料
Ryan Lopopolo（OpenAI）.Harness engineering: leveraging Codex in an agent-first world. 2026-03-11.InfoQ.AI Coding 2025年终清点：Spec正在蚕食人类编码，Agent造轮子拖垮效率，Token成本失控后上下文工程成胜负手. 2025-12-31.VentureBeat.EY hit 4x coding productivity by connecting AI agents to engineering standards. 2026.Stack Overflow Blog.Building shared coding guidelines for AI (and people too). 2026-03-26.

欢迎光临职贝云数AI新零售门户 (https://www.taojin168.com/cloud/)