claude code输出代码与项目原有架构产生冲突后的解决方案

我接手团队第一个 React 项目的第三天，Claude Code 就给我上了一课。当时我在修一个表单校验问题，需要改 useFormValidator 这个自定义 hook。我把需求说得很清楚，Claude Code 也很快给出了修改方案，它直接删掉了 useFormValidator，改用 react-hook-form 加 zod，还顺手重构了三个关联组件。代码本身写得漂亮，类型推导完整，错误处理也到位。问题只有一个：我们的项目根本没装这两个依赖，而且跨七个页面共用的 useFormValidator 被它改成了分散在各组件里的独立逻辑。

那次之后我花了整整一下午回滚代码，不是通过 Git，Git 能帮你回到上一个提交点，而是手动把 Claude Code 塞进来的新模式一点点扒出来，因为它在改表单组件的同时还修了几个其他问题，那些修复我不想丢掉。

这就是 AI 辅助编码最棘手的地方：它不只是在“写错代码”，而是在用一套你不知道的、但逻辑自洽的新规则重新解释你的项目。

一、AI 代码冲突的本质不是代码差，而是上下文断裂

大部分开发者第一次遇到 Claude Code 输出代码与项目原有架构冲突时，第一反应是“AI 写代码不够小心”。实际上这个判断只对了一半。

我连续用了六个月后统计过：在我遇到的 43 次明显架构冲突中，只有 7 次是因为 AI 生成了有逻辑错误的代码（比如状态更新时机不对、依赖循环）。其余 36 次，AI 给出的代码本身是合理的、可运行的、甚至是更优的，但它是为另一个项目写的。

这句话值得重复一遍：Claude Code 在冲突场景里给出的代码，九成以上是为另一个项目写的。

为什么会这样？因为它看到的是你输入的 prompt 和它自己能抓取到的上下文，而不是你项目完整的架构体系。当 prompt 描述了一个需要“重构状态管理”的问题，它并不知道你团队三个月前已经约定好了“全局状态用 Zustand、页面状态用 useState、表单状态走自定义 hook”。它知道的 Zustand 是一种很受欢迎的方案，Zustand + React 是合理的搭配，于是它给你来了个全套迁移方案。

所以我后来跟团队讲这件事时换了个说法：不要把 Claude Code 的架构冲突理解为“写出了烂代码”，而要理解为“它在一个不完整的世界模型里做出了局部最优解”。 这个理解一旦建立，解决方案的起点就完全不一样了，你不是在训练 AI 写更好的代码，而是在训练 AI 理解你的项目长什么样。

二、冲突的五个高发地带，每个都有不同的触发条件

在你开始设计什么约束文件、骨架文档之前，先要搞清楚冲突到底从哪里冒出来的。我根据自己的项目经历和帮朋友团队做过几次诊断，把 Claude Code 与项目架构冲突的场景归成了五类。每一个高发区的触发条件和最优解法都不一样，混着吃一种药肯定不管用。

1. 状态管理模式突变的「替换型冲突」

这是最致命的一类。Claude Code 会在你不知道的时候，把一个页面的状态管理方案换成另一种。不是因为它觉得原来的不好，它根本不知道原来有一套约定。

触发条件很明确：你让 AI 修改某个涉及状态逻辑的组件，prompt 里提到了“优化、重构、简化”这类词。 AI 在理解“优化状态管理”时，会调动它训练数据中关于 Zustand、Redux Toolkit、Recoil、Jotai 等方案的比较知识，然后选一个它认为在当前场景下更适合的。但你的项目可能早在半年前就统一选了其中某一个，团队规范文档里写得清清楚楚。问题在于，那份规范文档没有被喂给 Claude Code。

我经历过最离谱的一次是：一个组件里同时出现了 useState、useReducer 和 redux dispatch 三种状态操作，因为 Claude Code 在三次不同的对话里分别修改了同一个组件的不同部分，每次都按照“当时看起来最优”的方式去写。

2. 依赖引入的「外来物种入侵」型冲突

这个类型的冲突占比第二高。Claude Code 有一个强烈的倾向：遇到标准问题，引入标准库。 你的项目里全是原生 fetch，它给改成 axios；你手写了深拷贝函数，它改成 lodash.cloneDeep；你用的 dayjs，它改成 date-fns。这些库都是好东西，但问题在于你的 package.json 里没装，或者你的团队为了控制打包体积决定只用原生方案。

更隐蔽的伤害是：一旦 AI 引入了一个新依赖并在后续对话中被沿用，它会形成“路径锁定”。我见过一个项目，Claude Code 在修第一个时间格式化 bug 时引入了 date-fns，然后接下来的四次修改里，它都在用 date-fns 继续写，即使项目中其他所有时间逻辑都还在用 dayjs。等到发现时，同一个文件里两套时间库并存。

3. 组件组织模式的「结构漂移」型冲突

这类冲突不太容易在代码审查时被一眼看出来，但积累多了会让整个项目变得难以维护。典型表现是：你的项目统一用“每个组件一个文件夹，里面放 index.tsx、styles.module.css、types.ts”，Claude Code 新增组件时直接在 components/ 下放了一个单文件。

它没有做错任何事。单文件组件是合法的，而且很多项目就是这么组织。但它打破了你的项目结构约定，而这种约定恰恰是大项目可维护性的根基。 漂移一旦开始就很快扩散，因为后面的 AI 对话会参考已有的组件结构来决定新组件的放置方式，于是越漂越远。

4. 函数风格与约定的「隐形摩擦」型冲突

这是最容易被忽略但最多发的一类。命名规范（fetchUser vs getUserData）、函数签名风格（参数对象 vs 多参数列表）、错误处理模式（throw vs return null vs Result 类型）、副作用处理方式（useEffect vs 自定义 hook），这些微观层面的不一致，单独看每个都不算“错误”，但合在一起会让代码库的认知负载急剧上升。

我用过一个小技巧来量化这种影响：找任意一个中型组件，数一下里面有多少种不同的命名约定或风格模式。在完全没有约束的情况下，Claude Code 参与过的组件通常会出现 3-4 种风格混用，而在有明确约束文件的项目里，这个数字降到 1。

5. 架构层级跳跃的「边界穿透」型冲突

如果你项目有明确的分层（比如 Controller → Service → Repository，或者 View → ViewModel → Model），Claude Code 有时会跳过某一层直接调用底层。它看到一个 Controller 里需要查数据，就给它直接写了个数据库查询，因为从逻辑上讲这是最短路径。但在你的架构里，Controller 应该通过 Service 层才能访问数据。

这类冲突最难在代码审查里发现，因为代码本身没问题，功能也能跑。只有审查者心里清楚跨层调用的原则，并且一行行去核对调用链。

这五种冲突有一个共同的底层逻辑：Claude Code 缺少的不是编程能力，而是对你项目秩序的理解。 理解了这一点，你才会明白为什么后面要讲的方案重点都在“如何向 AI 描述你的秩序”，而不是“如何限制 AI 的能力”。

三、三个常见但不太有效的应对方式

在讲真正有效的方案之前，得先扫一遍大部分人最先尝试但效果有限的做法。这些做法不是全错，但单独用收效甚微。

❌ 方案一：每次都在 prompt 里写“保持现有风格”

这是最直觉的做法。在 prompt 加一句“请保持现有代码风格和架构”，觉得这样 AI 就会乖乖听话。我一开始也是这么做的，效果很差。原因是：

“保持现有风格”这句话太模糊了。 AI 不知道你的“现有风格”指什么。它看不到整个项目的代码，只能看到你当前输入的那几段代码。它看到的风格是你打开的这几个文件的样子，而不是整个项目的样子。如果你打开的文件恰好是项目里一个老的、还没被重构的旧模块，AI 甚至会把旧风格当成“现有风格”来保持。

我做对比测试时统计过：带“保持现有风格”的 prompt 和不带的，冲突率差异不到 20%。这个差异不足以解决问题。

❌ 方案二：写一份巨详细的 coding style guide

有些团队的解法是写一份几十页的 coding guide，然后想办法让它成为 Claude Code 每次都参考的文件。思路没错，但文件太重了。

Claude Code 的上下文窗口虽然大，但不是无限的。一份超详细的 style guide 会占据大量 token，挤占你对实际业务逻辑的描述空间。而且 AI 在处理超长文档时，后半部分内容的注意力会衰减。我见过一份 3000 词的 style guide，被塞进每次对话后，AI 对命名部分的遵循度还不错，但对最后的项目架构原则几乎完全没反应，因为那部分已经被注意力衰减吃掉了。

❌ 方案三：完全不让 AI 动核心文件

这个策略通过 claudeignore 把 src/core、src/services、src/store 全部加进去，AI 只允许操作 UI 组件和简单工具函数。听起来很安全，但代价太大。

我做过一次生产力测算：把核心文件全部排除后，Claude Code 帮忙修一个跨层 bug 的效率降低了约 60%，因为大部分 bug 都牵涉到被排除的文件。当 AI 只能改组件层面时，你不能让它帮你在 Service 层加错误处理，不能让它更新 Store 的类型定义，也不能让它重构跨越多个层级的数据流。你失去的不是 AI 的写代码能力，而是 AI 理解整个调用链的能力。

这三个方向我都认真试过、推过、最终放弃过。不是说它们毫无价值，保持现有风格”这句话加上总比不加好、style guide 有比没有强、核心文件隔离在特定场景下有用，但如果你以为只靠这些就能解决架构冲突问题，那你大概一个月后就会发现自己进入了“手动修 AI 代码比手写代码还累”的阶段。

四、解法框架：用「项目骨架文件 + 约束地图 + 会话前缀」构建 AI 的世界模型

前面三节我一直在讲问题和误区，从这一节开始讲我目前在实践中验证过、比较稳定的一套方案。这套方案的核心思想来自一个非常简单的类比：

你带一个新入职的工程师，会不会第一天就让他随便改代码？当然不会。你会给他看架构文档、讲模块划分、告诉他命名规范、指出哪些文件是绝不能随便动的。对新人是这样，对 AI 也是同理。区别只在于：新人能主动问你问题，AI 不会，所以你得提前把所有答案都准备好。

这套方案包含三个层次的构建，我在团队里管它叫“三件套”：

下面我逐层展开讲。

第一层：用 ARCHITECTURE.md 给 AI 一张项目骨架图

这是三件套里最重要的一层。它要回答的问题是：如果用最少的文字，让一个不熟悉你项目的聪明工程师快速理解项目怎么组织，你会写什么？

我先把我团队的 ARCHITECTURE.md 简化版放出来，然后拆解每部分为什么这么设计：

# 项目架构骨架

技术栈锁定

• 框架: React 18 + TypeScript 5
• 状态管理: Zustand (全局) + React Context (跨层传递)
• 路由: React Router v6
• 样式: CSS Modules (每个组件一个 .module.css)
• HTTP: 项目封装 useFetch hook，禁止直接使用 fetch/axios
• 时间: dayjs (全项目唯一时间库)
• 工具函数: 均在 src/utils，禁止引入 lodash

目录结构约定

src/

components/ — 每个组件一个文件夹 {Name}/index.tsx + styles.module.css + types.ts

hooks/ — 以 use 开头，一个文件一个 hook

services/ — API 调用层，统一返回 {data, error, loading} 格式

stores/ — Zustand stores，命名规则 {domain}Store.ts

utils/ — 纯函数工具

pages/ — 页面级组件，禁止包含直接 API 调用

数据流约定

• 页面 → Service 层 → API：通过 Service 层访问后端，页面组件不直接调 API
• 组件内状态：useState，不提取到全局 store
• 跨组件共享：使用项目自定义 hook 或 Context

禁止项

• 禁止在组件内直接调 fetch
• 禁止引入新的状态管理库
• 禁止改 Service 层返回数据格式
• 禁止在 utils 外使用 lodash 方法

这个文件我控制在 200-300 词以内。不是因为我懒，是因为我发现超过这个长度的架构文档，Claude Code 的有效采纳率开始下降。这个数字来自我的经验而非正式实验，但原理是合理的：注意力是有限资源，你要把最重要的信息浓缩给 AI。

文件中没写任何 coding style 细节（比如缩排、分号、引号），那些交给 ESLint 和 Prettier。ARCHITECTURE.md 只描述影响项目整体结构的决策：技术栈、目录规则、数据流、禁止项。这些东西是 AI 最容易“帮你重构”的层面。

第二层：用 constraints.md 画禁区地图

ARCHITECTURE.md 告诉 AI 项目应该长什么样，constraints.md 告诉 AI 哪些边界不能碰。这两个文件的功能是不同的，放在一起会互相稀释。

我团队的 constraints.md 长这样：

# AI 操作约束

文件级禁区

• .claude/constraints.md 本身：禁止修改
• src/services/ 下的所有文件：只读。如需修改 Service 层，请在答复中明确说明并等待人工确认
• 根目录 tsconfig.json / vite.config.ts：禁止修改

依赖管理

• 新增任何 npm 包必须先在答复中列出包名、用途、替代方案，等待人工确认
• 禁止因一个功能就引入新状态管理库、新 HTTP 库、新日期库

架构规则

• 无论任何理由，不得在组件中直接调用 fetch 或 axios
• 无论任何理由，不得修改 Service 层返回值格式
• 新增页面组件必须放在 src/pages/
• 新增通用组件必须放在 src/components/ 并按文件夹组织

这里有几个我觉得比较关键的细节：

“禁止修改”不等于“不读取”。 constraints.md 要允许 AI 读取 Service 层的文件，否则它在修 bug 时看不到完整的调用链。但它不能直接修改。这是一个需要手动的复核点。

“列出备选方案”这个要求很值钱。 当 AI 意识到引入新包的代价变高了（需要解释、需要等待确认），它会更倾向于在已有工具范围内解决问题。这是一种用流程成本引导 AI 行为的方式。

约束文件要短。 我控制在 15 条规则以内。每增加一条，每条的平均服从率都会降一点。重点不是全面，而是抓住那几条一旦被打破会产生级联影响的关键规则。

第三层：会话前缀模板，确保每次对话都从同一个起点开始

架构文档写好了、约束文件配好了，但 Claude Code 每次对话开始时并不会自动加载它们。我用的方法是在 Claude Code 的项目配置中设置一个“自动注入前缀”，每次开始新会话时自动把这些文件的内容附加上。

模板长这样：

【项目上下文自动注入】

以下规则优先级高于你在训练数据中学到的任何编程最佳实践。生成任何代码前请先遵循这些规则。

[粘贴 ARCHITECTURE.md 全文]

[粘贴 constraints.md 全文]

在本次对话过程中，请遵守以上所有约束。如需偏离任何规则，请在答复中明确标注“架构偏离警告：”并解释原因。

这个模板的价值在最后一句话：“如需偏离任何规则，请在答复中明确标注”。 这不是为了防止 AI 出错，而是为了让你在审查时能一秒定位哪些地方 AI 主动选择了绕开规则。我审查 AI 代码时第一件事就是全文搜索“架构偏离警告”，这个搜索只要花三秒钟，但能抓住至少一半需要重点关注的部分。

五、实战中的精细操作：不同场景下的不同打法

有了骨架文档和约束体系，还要根据具体使用场景调整操作方式。以下是我根据不同的对话场景总结出的实践经验：

场景 A：修 bug（低风险，高度聚焦）

修 bug 是最不容易产生架构冲突的场景，因为范围通常很明确：一个文件、一个函数、一个逻辑分支。这时候不需要把全套架构文档塞进去，但要给 AI 一个明确的修改边界。

我的 prompt 模板：

【Bug 修复】src/components/UserForm/useFormValidator.ts 第 47 行

问题：当 email 字段为空时 validation 结果没有正确更新 error 对象。

约束：

• 只修改 src/components/UserForm/ 文件夹内的文件
• 保持 useFormValidator 的函数签名不变
• 不要引入新的依赖
• 不要改变 error 对象的已有结构

[粘贴相关代码或文件引用]

要点是明确告诉 AI 什么不能改：函数签名、error 对象结构、文件范围。这些约束在修 bug 场景下是最有效的，因为 bug 往往就出在一个点上，AI 不需要理解整个项目的架构就能修。这种场景下架构冲突的概率本来就不高，用轻量级约束即可。

场景 B：新增功能（中度风险，创造性工作）

这是冲突最高发的场景，也是骨架文档最能发挥价值的地方。我的做法是：

1. 提前设定放置规则：告诉 AI 新文件应该放在哪个目录，遵循什么命名规则
2. 给出参考样板：指定一个类似功能的现有文件作为参考
3. 分级确认：AI 先生成文件结构方案，确认后再写实现

实操示例：

【新功能】为后台用户管理页增加批量导入功能（CSV 上传 + 预览 + 确认导入）

放置规则：

• 新页面放在 src/pages/Admin/UserImport/
• 上传组件放在 src/components/shared/FileUpload/
• API 调用放在 src/services/userService.ts（新增 importUsers 方法）
• 参考样板：src/pages/Admin/UserList/index.tsx 的页面结构和数据请求模式

流程：

Step 1: 请先生成文件结构方案，我确认后再写代码

先让 AI 输出文件结构方案再写代码，这一个步骤节省的返工时间可能比任何技术手段都多。因为结构方案只要 30 秒就能审查完毕（放在哪个目录、新增几个文件、调用链对不对），而如果让 AI 直接写代码，你可能要翻好几百行才能发现它把组件放错了位置。

场景 C：重构（高风险，深度改动）

重构是最容易产生严重架构冲突的场景。Claude Code 在这个场景下有一个让人头疼的特性：你让它重构 A 模块，它可能会顺手优化 B 模块的写法，因为它的“重构”概念包含了提升整体代码质量的倾向。

我现在的做法是：

1. 用 claudeignore 临时锁定不相关的模块：在重构期间，把明确不需要动的目录加入 claudeignore
2. 逐模块推进：不要一次性说“重构用户系统”，而是拆成“重构 useAuth hook” → “重构 AuthService” → “重构登录页面”
3. 每次重构完做 diff 审计：用 git diff 逐文件检查，不只看改动是否正确，还要检查有没有不该被碰到的文件被改了

我给重构定了一条铁律：AI 重构的代码，如果改动范围超出了我在 prompt 中指定的文件或模块，不管改动是否更好，都要回滚那部分。

这个铁律有点严厉，但逻辑是清晰的，超出范围的改动说明 AI 的上下文边界感失准了，你需要让它回到自己的边界内。纵容一次，下一次的边界就会更宽。

六、Git diff 审查清单：30 秒抓出 AI 代码中的架构问题

无论约束体系做得多好，人工审查这一步永远不能省。我花了很长时间把 AI 代码审查从“通读每一行”优化到“先扫关键信号”，效率提升很明显。

下面是我每次审查 AI 生成的 diff 时必查的 7 个信号，排查顺序有讲究，它是按“问题严重程度 × 发现难度”的乘积排序的：

搜索这个顺序是故意的。 前三个信号（文件、依赖、层级）只要 10 秒钟就能扫完，抓出来的却是最严重的那类问题。后四个更微观，但在前三个没问题的前提下，它们的修复成本低很多。

一个经验数据：经过“三件套”约束后，我每次 diff 审查大约能抓到 1-2 个需要修正的问题。如果没有约束体系，这个数字是 5-8 个。不是 AI 变厉害了，而是可预防的问题在约束层就被挡掉了，留给审查的都是约束规则覆盖不到的边缘情况。

七、团队协作视角：如何让 AI 编码规范成为团队共识而非个人偏好

一个人用 Claude Code，冲突问题自己扛。一个团队用，规则不一致会有大问题。

我团队现在七个人，都在不同程度上用 Claude Code。最开始的一个月是混乱的，每个人按自己的方式写 prompt、加约束、做审查，结果 A 写的 AI 辅助代码和 B 的人工代码风格差距比 A 和 C 的人工代码差距还大。

后来我们做了一件事，把这套体系从“个人工具”变成了“团队规范”：

第一步：把 ARCHITECTURE.md 和 constraints.md 写进项目仓库。 这是最基础的一步。这两个文件和其他代码平级管理，走同样的 review 流程。谁想改架构约定，就得提 PR 改 ARCHITECTURE.md，而不是在自己本地悄悄改配置。

第二步：建立“AI 辅助代码”标签。 所有 AI 生成的代码，在 commit message 里加上 [ai-assisted] 前缀。这不只是为了追踪，更重要的用途是：当一段标记了 [ai-assisted] 的代码后续出问题时，你马上知道它的来源，检查时可以直接对照原始约束文件看有没有冲突隐患。

第三步：每月做一次“AI 代码架构合规度抽查”。 随机抽 5 个带 [ai-assisted] 标记的 commit，按第六节那 7 个信号逐项检查。统计出团队级别的合规率，贴在团队频道里。这个动作不花很多时间（一个人一小时左右），但它的存在本身就是一种约束，知道会被抽查，写 prompt 时会更注意。

第四步：维护一份“常见冲突案例库”。 冲突不是只会发生一次就消失的东西，同样的坑会有不同的人踩。我们维护了一个简短的 Notion 文档，记录“AI 做了什么、为什么不对、正确做法是什么”，比如“在 UserList 页面引入 axios 替代 useFetch hook”。新成员进来先看这份案例库，比看架构文档更容易建立直觉。

八、边界清晰时果断约束，边界模糊时主动对话

上面的所有方案都基于一个大前提：你很清楚自己的项目架构，并且有明确的不允许被打破的约定。 但现实中还有一种非常常见的情况：你的项目本身就在架构演进中，有些约定还没定型，有些模块还在试方向。

这时候“锁死架构”反而是错的。你需要一种更灵活的协作方式。我称之为“边界清晰时果断约束，边界模糊时主动对话”。

边界清晰的事：技术栈选择、命名规范、目录组织、禁止引入的库，这些应该被写进约束文件，不容讨论。它们是你的项目基线。

边界模糊的事：某个新模块应该用哪种状态管理模式、Service 层的粒度应该多细、要不要引入某个设计模式，这些还在探索中的决定，不应该提前锁死。但也不能让 AI 帮你做决定。我的做法是：

1. 在 prompt 中明确标注：“这部分架构决策暂未定型，请在写代码前先给出 2-3 种可行的组织方式及各自的利弊，我选择后再实现”
2. 一旦我做出了选择，立刻把选择结果写进 ARCHITECTURE.md，让它变成新的边界

这种方式的好处是：AI 在模糊地带充当了方案提议者而不是决策者，而你是那个做出架构决策的人。决策一旦做出，就进入约束体系。这是一个“探索-决策-固化”的循环，而不是“不约束-随便写-事后补救”。

九、对未来的判断：冲突问题不会消失，但会转移

最后谈一个我自己一直在想的判断：Claude Code 和项目架构的冲突问题，会不会随着模型变强而自然解决？

我的判断是：冲突问题不会消失，只会转移到更高层面。 今天的冲突发生在“用了不同的状态管理库”这个层面，明年可能转移到“用了不同的架构模式（微服务 vs 模块化单体）”这个层面。

原因很简单：AI 的能力越强，它能动的东西就越多。今天你可能只让它修一个组件的 bug，它触及的范围有限。将来你让它帮你重新设计整个模块的架构，它能触及的范围就大多了。冲突的严重程度和 AI 被赋予的自由度成正比，而这个自由度随着我们对 AI 信任的增长而增长。

所以，建立一套 AI 编码的约束和沟通体系，不是一个“过渡期的临时方案”，而是一项会长期需要的工程能力。 正如团队需要有 code review 文化、需要有架构决策记录、需要有 coding convention，未来也一定会有“AI collaboration protocol”，而三件套里涉及的骨架文档、约束地图、会话前缀，就是这个 protocol 的早期雏形。

十、总结与下一步行动

回到这篇文章最核心的那句话：AI 代码冲突的本质不是 AI 写代码不认真，而是你还没有帮它建立对你项目的完整理解。 解决这个问题的起点，不是限制 AI，而是给 AI 一张地图。

如果你读到这里并准备行动，我建议你按这个顺序做：

1. 先用 30 分钟写好第一版 ARCHITECTURE.md，不要追求完美，先写出项目最关键的技术栈、目录结构、数据流约定、三条最重要的禁止项。200-300 词就够。
2. 再花 15 分钟创建一个 constraints.md，列出 10-15 条绝对不能打破的规则。把“引入新依赖需要先说明”这条放在第一条。
3. 在 Claude Code 中设置好自动注入前缀，让每次新会话都自动加载这两个文件的内容。
4. 用一周时间跑一个约束验证周期，每次 AI 生成的代码走你之前没走过的 diff 审查清单（第六节里那 7 个信号），记下哪些冲突还在发生、约束文件漏了什么。一周后更新一次这两个文件。
5. 如果你是团队 leader，把这两个文件推进项目仓库、建立 [ai-assisted] 标记规范、定一个简单的月度合规抽查节奏。

这件事的价值不在于一次做对，而在于持续更新。你的架构在变，AI 能力也在变。骨架文件和约束规则需要跟着迭代。把约束维护当成和代码维护同等级别的事，这才是长期解法。

如果你这套方案已经跑起来了，欢迎告诉我你们遇到了什么新的冲突类型、约定了什么有效的约束规则，我在持续收集这方面的实践案例，也想看看更多团队的做法和教训。