01-两个颠覆认知的原则

两个颠覆认知的原则

这两个原则，是我们踩了无数坑、交了无数学费之后才想明白的。

---

原则一：AI时代软件研发是"平的"

一句话说清楚：别再往自己的代码上堆框架了，AI理解不了那么多层。

这个认知是怎么来的？

2025年上半年，我们团队就遇到了这个问题。

当时项目里用了好几层框架：业务层、工具层、各种中间件。看起来很"规范"，很"企业级"。

但当我们让AI参与开发时，问题全暴露出来了：

• AI完全搞不懂这些框架之间的关系
• 每次都要从头解释一遍这个框架是干嘛的、那个中间件有什么用
• 调试时，AI给的方案要么不work，要么改了这里坏那里
• 团队成员自己都要翻半天文档才能搞清楚

我们突然意识到：不是AI太笨，是我们把事情搞太复杂了。

---

传统开发的"塔式结构"（AI看不懂）

你的业务代码
    ↓
一堆业务框架（React/Vue/Spring...）
    ↓
各种工具库（Lodash/Utils...）
    ↓
中间层1（你自己都快忘了是干嘛的）
    ↓
中间层2（上次是谁加的？）
    ↓
中间层N（天知道还有多少层）
    ↓
底层API

这种结构的问题：

❌ 每加一层，AI理解的难度就翻倍

• AI："这个框架是干嘛的？"
• 你："这是一个状态管理工具..."
• AI："那它和那个工具是什么关系？"
• 你："呃...让我查查文档"

❌ 调试像在走迷宫

• 出了bug，AI说要改这里
• 改了之后，那里又崩了
• 来来回回，半天过去了

❌ 维护成本指数增长

• 框架升级，API变了，AI全懵了
• 你自己都头疼，更别说教AI了

❌ 你的手脚被框架捆住了

• 想这样实现？框架不支持
• 想那样优化？框架限制你
• 最后你只能说："这个框架不行"

---

AI Native的"扁平结构"（AI秒懂）

你的业务代码
    ↓
项目特定的语义化规则（用自然语言写的）
    ↓
底层API（AI天生就懂）

这种结构的好处：

✅ AI理解无障碍

• 底层原理AI早就知道了
• 不需要你教它框架API
• 它知道的是"本质"，不是"封装"

✅ 调试直达问题

• 没有中间层干扰
• 出了问题，一眼看到底
• AI给的方案，一改就work

✅ 维护成本可控

• 代码量少了，逻辑清晰了
• 新人上手快，AI也快
• 你自己看得懂，AI也看得懂

✅ 完全掌控规则

• 规则你定义，不是框架定义
• 需要改？直接改规则
• 不用等框架升级，不用求框架支持

真实案例：测试体系的两条路

场景：项目需要加测试。

❌ 传统做法（我们的老路）：

你：需要测试。 ↓ 找了个现成框架（Jest/Mocha） ↓ 开始啃文档，学API ↓ 配置测试环境，踩一堆坑 ↓ 好不容易写几个用例 ↓ 遇到特殊场景：框架不支持？ ↓ 你："这个框架不行，换一个？" ↓ 又来一遍...

结果：

• 时间：3天过去了
• 心态：累了，想摆烂
• 结论：测试好难，以后再说吧

---

✅ AI Native做法（我们现在的方式）：

你：需要测试。这是我的测试需求，用大白话写清楚就行。 ↓ AI：我懂了。需要覆盖哪些方法？ 你：这些，那些。 ↓ AI：每个方法测什么场景？ 你：正常场景、异常场景、边界情况。 ↓ AI：好的，那我生成个测试工具：

• check-test-coverage.js（自动分析覆盖哪些方法）
• 自动生成测试用例
• 生成校准矩阵和报告 ↓ 你：跑一下...嗯，这个分支没覆盖到。 ↓ 你：加一条规则，这个方法还要测XXX情况。 ↓ AI：好的，更新用例。

结果：

• 时间：半天搞定
• 心态：轻松，有掌控感
• 结论：测试也就这样嘛

---

关键差异：

传统做法	AI Native做法
依赖外部工具	自建规则体系
工具不支持？换工具！	规则不够？改规则！
被框架牵着走	自己定义规则
学习成本高（学API）	学习成本低（写规则）
维护成本高（框架升级）	维护成本低（规则调整）

---

AI Native的4条生存法则（背会能救命）

法则1：戒掉框架依赖

别人的轮子再好，不如自己造辆马车。

• 不是重复造轮子，是为自由选择的权利
• 今天被框架绑架，明天就被AI淘汰

记住：框架是AI理解的最大障碍。

AI："你这个框架有7层抽象...我放弃了。"

---

法则2：说人话，不说黑话

AI不是百科全书，是外国人。

• 技术术语是AI的第二语言，它学得很慢
• 用最简单的中文，让AI秒懂

错误示范：

你: "实现一个基于JWT的SSO认证中间件"
AI: "???"（3个问号代表它要猜3次）

正确示范：

你: "写个登录功能：用户输入账号密码，验证成功后返回一个加密字符串，下次用户带着这个字符串来就不用再登录了"
AI: "好的！"（秒懂）

---

法则3：你定义"测什么"，AI负责"怎么测"

别替AI写代码，让它自己写。

• 你：定义规则（用什么技术、测什么场景）
• AI：生成实现（写测试代码、写运行脚本）

你的价值在规则设计，不在代码编写。

---

法则4：规则优于工具，随时可进化

工具升级要等别人，规则优化你自己说了算。

• 工具：别人升级，你等着
• 规则：你随时改，AI随时执行

AI时代的真理：

你的规则体系，就是你的核心竞争力。

---

---

关键认知：做永远比说重要

这句话听起来像鸡汤，但它是我们用半年时间验证出来的真理。

我们踩过的坑

2025年上半年，团队里有各种"AI专家"：

• 小A：收藏了100多篇Prompt工程文章，理论一套一套的
• 小B：参加了3个AI培训班，证书拿了好几个
• 小C：每天在群里分享AI技巧，看起来很懂

但实际项目里呢？

• 小A：让AI写个函数，结果写错了一堆，他还不知道怎么改
• 小B：遇到复杂任务，AI搞不定，他只会说"AI太弱"
• 小C：分享的技巧看起来厉害，但实战中一个都用不上

问题出在哪？

他们都在"说"，没有在"做"。

什么是"说"？

❌ 看了10篇Prompt Engineering文章，就以为懂了 ❌ 听了AI培训课，就以为会用AI了 ❌ 收藏了100个技巧，却从未实际应用 ❌ 只会说"AI不行"，却从未探索AI的边界在哪里

什么是"做"？

✅ 每天用AI写代码、调试、重构 ✅ AI搞错了，分析为什么会错 ✅ AI误解了，思考怎么问才对 ✅ 踩坑了，记录下来，下次避免

核心差异：

"说"	"做"
知识是别人的	知识是自己的
没有体感	有真实感受
理论完美	实战验证
遇到情况不会用	知道怎么用

---

理解AI的三个层次（你在哪一层？）

Level 1：知道AI能做什么（表层）

这是最浅的层次。

• AI能写代码、生成测试、写文档
• 这些看别人演示就知道了
• 状态："哇，AI好厉害！"

这个层次，你还在"看"。

---

Level 2：识别AI的"死穴"（边界认知）

这是从"小白"到"高手"的分水岭——

也是你开始交学费的阶段。

AI的"死穴"在哪？

❌ 在复杂业务逻辑前，AI会"瞎猜"

• 你："帮我写个支付系统"
• AI："好的！"（生成了一堆代码）
• 你：（跑了一下，bug满天飞）
• 你："哦，原来AI不懂什么叫'幂等性'"

❌ AI的自信，往往与正确性成反比

• AI："这个代码没问题！"（自信满满）
• 你：（一运行，直接崩溃）
• 你："你说没问题就没问题？！"

❌ 这些教训，不是看会的，是踩坑踩出来的

• 代码会教给你
• Bug会告诉你
• 线上故障会狠狠地"教育"你

这个层次，你开始"用"了——

用血泪经验，换来对AI边界的理解。

---

Level 3：理解AI的思维模式（本质） ⭐️

这是最高层次，也是最难达到的。

• AI如何理解上下文？
• AI为什么会误解指令？
• AI的"推理"过程是什么样的？

这个层次，你在"懂"了。

真实场景：

你：AI，帮我优化这个函数。 AI：给出方案A。 你：不对，我真正要的是XXX。 AI：明白了，给出方案B。

关键：你开始理解AI为什么会误解，怎么问才对。

这个层次，需要大量实践+反思。

---

为什么"做"比"说"重要？

我们团队有个活生生的例子——

小李，团队里的"AI扫地僧"。

他的背景？

• 理论？不存在的（AI技术文章一篇没看过）
• 技巧？懒得记（Prompt Engineering是什么鬼？）
• 培训？从不参加（"太浪费时间"）

但他每天都在"驯服"AI：

🕐 9:00 AM - 开始写代码 AI写错了？打回去重写！ 改对了？奖励，记下来！

🕒 3:00 PM - AI又抽风了 换种问法？试试！ 还不对？分析AI的"小心思"

🕕 6:00 PM - 复盘总结 研究透了？记成"AI驯服手册"

半年后，神奇的事情发生了：

小张（遇到AI难题）："找小李去！"

老王（被AI气得想砸电脑）："小李，救我！"

小李（淡定地打开他的"驯服手册"）：

"哦，这个问题啊，AI在第3步会'想当然'，你得这样问..."

他能说出大道理吗？ 不能。

但他知道——怎么让AI这只猛兽，乖乖听话！

价值	说明
建立直觉	用过100次AI，比看100篇文章更有用
发现边界	只有试过才知道AI在哪里会犯错
理解思维	大量对话后，你会"感觉"到AI的思维模式
验证理论	书上说的对不对？试过才知道

---

5个实践建议（从今天开始）

1. 每日实践：每天至少用AI完成一个实际任务

   • 不是"试用"，是"真实使用"
   • 写代码、写文档、改bug都行

2. 记录边界：记录AI能做什么/不能做什么

   • AI能：生成CRUD代码、写简单测试
   • AI不能：理解复杂业务、保证100%正确
   • 这是你的"AI能力地图"

3. 复盘误解：每次AI误解你，分析原因

   • 为什么会误解？
   • 我该怎么问？
   • 下次怎么避免？

4. 对比学习：同样的问题，不同问法效果差异巨大

   • 问法A：AI给了一堆不对的
   • 问法B：AI一下就对了
   • 为什么？记录下来

5. 持续更新：AI在进化，你的认知也要更新

   • 今天的认知，明天可能就过时了
   • 保持开放心态

---

核心洞察

你能"读懂"AI的程度，不取决于：

• 看了多少文章
• 参加了多少培训
• 收藏了多少技巧

而是取决于：

• 用过AI的次数（量）
• 探索过多少边界（广度）
• 理解多少失败案例（深度）
• 反思过多少误解问题（本质）

一句话：不是看多少文章，而是踩过多少坑。

---

原则二：从根上AI化

一句话说清楚：别只是给现有流程加AI，要从根上重新思考怎么开发。

这个认知是怎么来的？

2025年6月，我们开始用AI开发医疗护理系统。

一开始，我们就做了表面AI化：

• 给每个程序员装了Copilot
• 建了个AI讨论群，让大家有问题就问ChatGPT
• 买了几门AI课程，让大家学习Prompt工程

然后呢？

一个月后，大家发现：

• "AI不懂我们的框架，写出来的代码没法用"
• "AI写的代码不符合我们的规范"
• "AI只能做简单任务，复杂的不行"
• "AI还太弱，等它更强大吧"

问题出在哪？

我们只是在现有流程上加了AI工具，但没有改变开发方式。

这就像：你给一辆马车装了个飞机引擎，但还是在地上跑。

---

什么是"表面AI化"？（我们的老路）

现状：团队用传统方式开发

• 前端用React+Redux+一堆中间件
• 后端用Spring+各种框架
• 测试用Jest，配置几百行

操作：加AI工具

• 安装Copilot
• 用ChatGPT聊天
• 买AI课程

结果：

你：AI，帮我写个用户登录功能。 AI：生成了一堆代码... 你：不对，这个不符合我们的规范。 AI：那我改一下... 你：还是不对，我们这里用的是那个框架的XXX方式。 AI：哦，那我再改... 你：算了，我自己写吧。

结论：

• "AI太笨了"
• "AI不懂我们的框架"
• "AI还太弱，等它更强大"

这是错的。

不是AI太弱，是你还在用老方式开发。

---

什么是"从根上AI化"？（我们现在的方式）

第一步：思维模式转变

从传统开发 → AI协作开发

• 从"命令AI" → 到"与AI协作"
• 从"代码生产者" → 到"规则设计者"
• 从"依赖工具" → 到"定义规则"

第二步：项目级AI化设计

问自己三个问题：

• 架构是否AI友好？（能看懂、能解释）
• 规范是否语义化？（用大白话写清楚）
• 工具是否可解释？（AI能理解用途）

第三步：构建AI Native基础设施

• 语义化规则库（用自然语言写的规范）
• 项目特定技能包（AI能调用的工具）
• 上下文管理系统（AI的记忆）
• 经验积累机制（踩过的坑）

第四步：AI驱动开发

现在的工作方式：

1. 你：定义规则（用大白话说清楚要什么）
2. AI：理解规则，生成代码
3. AI：自测验证
4. 你：审核，没问题就合并

遇到问题怎么办？

问题	传统做法	AI Native做法
AI搞不懂	"AI太弱"	"规则不够清晰" → 优化规则
AI写错代码	"AI不行"	"上下文缺失" → 补充上下文
AI能力不足	"等AI更强"	"扩展工具链" → 加技能包

结论：持续优化，不是等着AI变强，而是让我们变得更会AI化。

---

AI化的四个层次（你在哪一层？）

Level 1：工具层AI化 - 入门

你在用什么？

• ✅ AI编程助手（Copilot/Cursor）
• ✅ AI聊天工具（ChatGPT/Claude）

你的状态？

• "我安装了Copilot"
• "有问题我就问ChatGPT"
• "AI帮我写点小代码"

问题：还在用老方式开发，只是加了AI工具。

---

Level 2：流程层AI化 - 进阶

AI怎么参与？

• ✅ AI参与开发流程
• ✅ AI辅助Code Review
• ✅ AI生成测试

你的状态？

• "开发流程里AI参与进来了"
• "写完代码让AI帮忙看看"
• "测试让AI帮忙生成"

问题：流程变了，但思维还是老的。

---

Level 3：规则层AI化 ⭐️ 关键分水岭

这才是真正的AI Native。

你在做什么？

• ✅ 用自然语言定义语义化规则
• ✅ 建立项目特定技能包
• ✅ 有上下文管理系统

你的状态？

• "规则我定义，AI负责执行"
• "遇到问题，我优化规则"
• "AI理解我的项目规范"

这才是从根上AI化。

---

Level 4：理念层AI化 - 成熟态

你的思维模式？

• ✅ AI First思维（凡事先想"怎么用AI做"）
• ✅ 扁平化架构（不依赖复杂框架）
• ✅ 规则驱动开发（规则优于工具）
• ✅ 持续学习优化（AI在进化，我也在进化）

你的状态？

• "我已经忘记怎么不用AI开发了"
• "AI是我的一部分，不是工具"
• "我在用AI的方式思考"

这是AI Native的终极形态。

---

如何判断自己是否"从根上AI化"？（4个维度自查）

✅ 维度1：思维模式

问自己3个问题：

❓ 遇到问题时，你的第一反应是？

• ❌ "找个工具/框架来解决"
• ✅ "如何让AI理解这个问题"

❓ 遇到需求时，你的第一反应是？

• ❌ "调用哪个框架API"
• ✅ "如何定义规则让AI实现"

❓ 代码Review时，你关注什么？

• ❌ "API调用是否正确"
• ✅ "规则是否清晰，AI能否理解"

如果都是✅，你的思维已经AI化了。

---

✅ 维度2：项目设计

检查你的项目：

❓ 项目架构

• ❌ 复杂多层，一堆框架
• ✅ 扁平化，AI能看懂

❓ 编码规范

• ❌ 技术术语，晦涩难懂
• ✅ 用大白话写，AI能理解

❓ 工具链

• ❌ 依赖外部黑盒工具
• ✅ 自建，可解释、可调整

如果都是✅，你的项目已经AI化了。

---

✅ 维度3：能力建设

你有什么？

❓ 规则管理

• 有语义化规则库（用自然语言写的）
• 规则能被AI理解和执行

❓ 工具体系

• 有项目特定技能包
• AI能调用这些技能包

❓ 上下文管理

• 有上下文管理系统
• AI能记住项目历史

❓ 经验积累

• 有踩坑记录
• 有最佳实践库

如果都打勾，你的基础建设已经到位了。

---

✅ 维度4：实践效果

看实际效果：

❓ AI能理解你的项目核心逻辑吗？

• ❌ 每次都要从头解释
• ✅ AI懂业务、懂规范

❓ AI生成的代码符合规范吗？

• ❌ 总是要大改
• ✅ 基本不用改，或小改即可

❓ 新人上手快吗？

• ❌ 要老员工手把手教
• ✅ 看规则库就能理解

❓ 遇到问题怎么解决？

• ❌ "这个工具不行，换一个"
• ✅ "规则不够清晰，优化一下"

如果都是✅，你已经真正AI Native了！

---

实践路径（从今天开始，4个阶段）

阶段1：清理依赖（1-2周）

做什么？

• 盘点现有依赖和中间层
• 识别哪些是"真正需要"的
• 砍掉那些"可以自建"的部分

目标：减少不必要的复杂度。

---

阶段2：语义化规则（2-4周）

做什么？

• 用自然语言描述项目规范
• 别用技术术语，用大白话
• 建立规则索引和检索系统
• 让AI学习并验证规则

目标：AI能读懂你的规范。

---

阶段3：构建技能包（持续）

做什么？

• 提取项目特定能力为技能包
• 让AI调用技能包而非框架
• 持续优化和扩展

目标：AI能用你的工具。

---

阶段4：持续优化（长期）

做什么？

• 记录AI使用中的问题
• 分析是规则问题还是能力问题
• 迭代优化规则和能力

目标：越来越强。

---

工作区治理：路径语义 > 记忆力

核心理念：不能指望"每个人都记得应该改哪个文件"，只能指望"结构与规则会把人带到正确的位置"

目录语义（推荐）：

public/              → 公共资产（agents/skills/models/workspace）
projects/            → 项目集合（每个项目自成体系）
  └─ {project}/ai/   → 内部维护资料（可引用仓库路径）
  └─ {project}/skill/→ 可发布技能包（必须自包含）

边界原则（很重要）：

1. skill必须自包含

   • 原因：skill的目标是可发布、可迁移
   • 如果引用项目外文件，一发布就断链

2. ai文档可以引用仓库路径

   • 原因：ai文档是"维护说明书"，需要指向真实文件与规范

规则落地四要素：

• 强制/建议级别
• 适用范围（目录树）
• 可执行动作（做什么）
• 验证方式（怎么证明做到了）

实践价值：

• 后面再多分支、多项目也不会乱
• AI不会"写着写着把规则写丢了"
• 新人能直接照做，AI在新会话也能正确执行

---

经验资产化：把经验变成组织资产

核心理念：规则没写下来=没有规则。更残酷一点：规则没写进AI能读懂的地方=AI会忘

AGENTS/agent/skill三层体系：

（1）AGENTS.md（项目级）

• 作用：约束智能体在该目录树内如何工作
• 内容：路径、测试规范、输出格式、边界
• 示例：

  # 项目约束
  - 测试必须写入会话目录（不能用/tmp）
  - 发布产物不能混进测试入口
  - skill必须自包含
  
  # 执行规范
  - 每次修改必须有中文多行提交信息
  - 单元测试必须有覆盖标注
  

（2）public/agents/*.agent.md（公共智能体）

• 作用：把团队的通用工作法固化成"执行规范"
• 内容：路由、输出、测试策略
• 价值：让不同项目共享
• 示例：通用测试agent、代码审查agent

（3）skill/（可发布runbook）

• 作用：面向场景的"怎么做"
• 要求：自包含、可迁移
• 价值：跨项目复用
• 示例：WEB前端自动化工具、单元测试环境生成

什么时候写哪个？

• 项目级约束 → 写AGENTS.md
• 团队通用规则 → 写public agent
• 面向执行场景 → 写skill

经验沉淀的升级路径：

口头约定
    ↓ (重复使用或踩坑)
项目规则（AGENTS）
    ↓ (跨项目复用)
公共规范（agent）
    ↓ (场景化)
场景runbook（skill）
    ↓ (持续优化)
测试模板/最佳实践

关键价值：

• 新人能直接照做
• AI在新会话也能正确执行
• 组织资产可复用、可迁移
• 规则没写进AI能读懂的地方=AI会忘

---

相关章节：

• 为什么AI不听你话？ - 深入了解AI使用中的常见问题
• 别把AI当工具 - 详细的工作流程和最佳实践

← 返回序章 | 继续阅读 →

---

📖 在线阅读：juejin.cn/post/758868…