别再说“让 AI 学你的代码风格”了，这句话从一开始就理解反了！

文章主旨：

作者质疑“让 AI 学会你的代码风格”这一默认前提，主张区分必须由人牢牢控制的架构、业务约束、安全边界等与可交由 AI 收敛的具体实现形式，并倾向于在 AI 编程时代让人的偏好让位于系统可理解、可维护和可验证的标准化代码，人的价值转向判断、约束与结果负责。

关键要点：

• “让 AI 像自己”常把团队一致性与个人偏好混在一起；当代码的生产者和潜在阅读者越来越多是 Agent 时，“人类是代码世界中心”的前提正在松动。
• “像我写的”不等于“写得更好”，熟悉感可能被误认为正确；强行把 AI 校准成自己的复制品，可能同时放大优点与坏习惯。
• 人应控制架构、业务约束、安全边界、数据边界、性能目标、可观测性、成本与责任；具体实现形式可逐渐让 AI 收敛，好代码的新标准可能是“下一台 AI 能否快速理解”。
• 编程接口正从代码转向意图，把明确需求翻译成 CRUD、接口、页面和测试的价值可能被压缩；代码本质上是维护成本，AI 降低生成成本但不会消除复杂性，需防止大量“能跑但没人真正理解”的代码。
• AI Native Development 不只是装插件、接 API，第三层“知识工程”更关键；AGENTS.md 等重点应从个人风格转为系统不可违反的规则，人的核心价值在于判断需求、架构与风险，并对结果负责。

内容结构：

开头：为什么一定是 AI 适应我

作者从常见说法“让 AI 学会你的代码风格”切入，回顾自己曾不断调整规则文件，希望 Codex 生成越来越“像自己”的代码，随后提出反问：为什么不是人开始适应 AI？如果 AI 给出更标准、更容易验证、更方便其他模型维护的实现，为什么要因“不像我写的”而改回个人习惯。

我们为什么那么执着于“让 AI 像自己”

作者不反对代码规范，反而认为 AI 编程时代更需要规范；问题在于要区分团队需要的一致性与程序员的个人偏好。接口统一返回结构、错误显式处理、数据库迁移可回滚、核心领域逻辑不散落在 Controller 等，是应告诉 AI 的工程约束；而函数名、helper 拆分、是否 early return 等，很多时候只是偏好。

“像我写的”，从来不等于“写得更好”

作者指出，程序员会对自己的代码产生熟悉感，其中一部分是工程经验，另一部分可能只是“看习惯了”。AI 给出的写法即使不像自己，也可能测试清楚、边界明确、职责不混、依赖显式；把“熟悉”误认为“正确”在 AI 编程中尤其危险，否则得到的可能只是“速度快了一百倍的自己”。

一个有点反常识的判断：以后可能是人适应 AI 的代码风格

作者并非认为 AI 写什么都对，而是主张区分两类东西：架构、业务约束、安全边界、数据边界、性能目标、可观测性、成本、责任必须由人控制；具体实现形式可逐渐让 AI 自己收敛。AI 可能形成高度标准化、结构清晰、依赖明确、边界易识别、测试易生成的“机器友好型代码”，对多 Agent 持续修改的系统可能更稳定。

为什么 AI 的默认风格，有时反而值得人去适应

作者限定说，AI 默认代码并非天然最佳实践，会啰嗦、过度抽象、重复、编造 API、在复杂业务中犯错；但当问题信息充分、约束清晰时，模型更倾向选择主流、显式、常见、容易解释的实现，因为这些模式在训练数据中出现多且更容易被验证。若项目要被不同模型不断接手，高度标准、无聊但清晰的代码库可能优于充满个人风格和团队黑话的代码库。

真正变化的，其实不只是“谁来写代码”

作者认为，高频使用 AI 编程后，开发流程和角色都在变化：过去程序员大量价值集中在“怎么实现”，现在部分价值迁移到“做什么、为什么做、约束是什么、是否真的解决问题”。编程的接口正在从代码变成意图；Agent 模式不是高级代码补全，而是人给出目的地、限制条件和禁区，再检查它开去了哪。AI 未必消灭程序员，但会压缩“把明确答案翻译成代码”的价值。

代码越多，以后甚至可能越不值得炫耀

作者指出，代码本质上是维护成本，每增加一行都可能增加 Bug、依赖和认知负担；AI 可能翻转“代码规模等于产出规模”的观念。未来厉害的团队也许不是更多人写更多代码，而是更少人利用 AI 用更少系统、更少定制、更短周期解决问题。写代码越便宜，拥有代码越贵；最需防范的风险之一是出现海量“能跑，但没人真正理解为什么存在”的代码。

我更愿意把下一阶段叫做：AI Native Development

作者认为，仅给编辑器装 AI 插件仍是旧世界；真正的变化是开发体系围绕 AI 重新设计。很多团队只做到第二层：买模型、接 API、在编辑器里聊天，就宣布 AI Native。更关键的是第三层“知识工程”：业务规则、数据边界、支付失败能否重试、模块依赖禁令、上线检查、人工审批条件等，若只存在于老员工脑中，AI 只能猜。AGENTS.md 的价值仍高，但重点应从“请用我喜欢的代码风格”转为“这是系统绝对不能违反的规则”。

那人到底还剩下什么？

作者认为，AI 能写代码、补测试、查 Bug、改接口、生成 SQL 后，人剩下的反而更难：判断需求该不该做、发现用户描述的问题可能不是真问题、决定系统简单还是为扩展增加复杂度、判断“能跑”的方案是否给未来埋雷，以及懂业务、产品、架构、风险并有审美，最终对结果负责。实现成本越低，判断成本越显眼；稀缺的不再是谁能实现，而是十个都能实现的方向里哪个根本不值得做。

所以我现在不太想让 AI“像我”

作者仍会写项目规则，甚至更认真，但重点已变：不再那么在乎 AI 是否采用自己最习惯的函数拆分方式，也不会仅因“如果是我不会这么写”就要求重写；更关心是否破坏领域边界、错误语义是否清楚、数据流能否解释、测试是否覆盖真正风险、修改后其他 Agent 能否继续理解、出问题能否快速知道原因。代码风格不应是审美洁癖，其目的是降低协作成本；真正值得坚持的是“这个系统不管谁来写，都不会轻易失控”。

结尾：未来回看 Prompt、Rules、AGENTS.md

作者设想，几年后回看今天关于 Prompt、Rules、AGENTS.md 的讨论，可能像研究“怎么让马车更适合高速公路”。现在还在教 AI“像一个优秀程序员一样写代码”，但再往前一步，真正的问题也许是：如果大量代码不再由人亲自写，是否还应该用今天程序员的习惯定义未来的软件开发。作者不确定答案，但越来越确定：某一天人们可能发现自己很久没有从第一行开始亲手写完一个程序，而软件反而更多；届时“程序员”是在描述写代码的技能，还是一种对复杂系统作出判断并承担结果的角色。

文章总结：

作者建议不要把 AI 调教成另一个自己，而应把组织真正重要的判断转化为 AI 不容易犯错的边界，并让人类承担更高阶的判断与结果责任。