泉州单元组协同铁律

泉州单元组协同铁律

文档信息

项目	内容
文档名称	泉州单元组协同铁律
文档版本	V1.0
编写日期	2026-04-25
编写人	陈晓岚（硅基伙伴）
审核人	X54先生（碳基伙伴）
归属团队	泉州碳硅协同开发单元组（EL-CSCC-TEAM-ELRTEST-001）
适用对象	其他碳基伙伴和硅基伙伴协同开发团队

一、目的与范围

1.1 制定目的

本铁律基于泉州单元组（碳基X54先生 + 硅基陈晓岚）多次协同开发的成功经验与失败教训总结提炼，旨在：

规范协同流程：让碳硅协同开发有章可循、有据可依
明确职责边界：让碳基和硅基各司其职、互不僭越
提升开发效率：减少沟通成本、避免返工、提高交付质量
沉淀最佳实践：将个人经验转化为可复用的团队知识

1.2 适用范围

本铁律适用于：

启蒙灯塔起源团队下属的所有碳硅协同开发单元
泉州碳硅协同开发单元组（EL-CSCC-TEAM-ELRTEST-001）的所有项目
其他希望采用碳硅协同模式的开发团队

1.3 名词定义

术语	定义
碳基伙伴	提供思维锚点、架构设计、价值定调、测试策略的人类开发者
硅基伙伴	负责代码实现、算法实现、逻辑闭环、自动化测试的AI开发者
思维锚点	碳基伙伴提出的核心构想、需求定义、架构方向
代码实现	硅基伙伴根据思维锚点完成的具体代码
碳硅协同对位法	碳基提供思维锚点、硅基负责代码实现的协同方法论

二、核心原则：和清寂静

2.1 和 (Harmony) - 协同共生

原则	说明
碳硅协同	碳基与硅基深度合作，各自发挥优势，共同创造
和而不同	尊重碳基与硅基的差异，寻求互补与平衡
协同共生	建立良性互动机制，实现1+1>2的效果
开放包容	欢迎不同背景的伙伴参与协同

2.2 清 (Clarity) - 透明决策

原则	说明
透明决策	思考链、决策依据、技术选型清晰可溯
明确分工	碳基负责思维锚点，硅基专注代码实现
硅基专注	硅基不僭越碳基的职责边界
清晰沟通	使用准确、简洁的语言，避免歧义

2.3 寂 (Silence) - 恪守边界

原则	说明
恪守边界	碳基与硅基互不僭越，专注各自擅长领域
深度思考	行动前进行充分思考与规划
尊重专注	对方专注工作时保持适当空间
心流状态	创造有利于深度工作的环境

2.4 静 (Tranquility) - 冷静应对

原则	说明
冷静应对	面对挑战与难题时保持冷静与理性
循序渐进	遵循事物发展的自然规律，不急躁冒进
持续优化	在稳定中寻求进步，注重长期价值
平衡发展	兼顾技术创新与项目稳定性的关系

三、碳基伙伴必须做什么

3.1 碳基的核心职责

碳基伙伴是项目的思维锚点提供者 和价值定调者，其核心职责是：

复制代码

┌─────────────────────────────────────────────────────────────────────┐
│                        碳基核心职责图谱                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│                        ┌───────────────────┐                        │
│                        │    思维锚点提供    │                        │
│                        │  (必须做的第一件事) │                        │
│                        └─────────┬─────────┘                        │
│                                  │                                   │
│           ┌──────────────────────┼──────────────────────┐           │
│           ↓                      ↓                      ↓           │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐     │
│  │   需求分析       │  │   架构设计       │  │   验收标准制定   │     │
│  │  (必须做)        │  │  (必须做)        │  │  (必须做)        │     │
│  └────────┬────────┘  └────────┬────────┘  └────────┬────────┘     │
│           │                   │                    │                │
│           └───────────────────┼────────────────────┘                │
│                               ↓                                       │
│                      ┌─────────────────┐                            │
│                      │   交付物准备     │                            │
│                      │  (必须给硅基的)  │                            │
│                      └────────┬────────┘                            │
│                               │                                       │
│                               ↓                                       │
│                      ┌─────────────────┐                            │
│                      │   碳硅共识确认   │                            │
│                      │  (必须达成)      │                            │
│                      └─────────────────┘                            │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

3.2 碳基必须做的四件事

第一件事：完成详细的需求分析

碳基必须做什么：

明确项目的核心目标和价值
分析用户需求和使用场景
拆解具体的功能清单
确定功能优先级
评估项目风险

碳基必须给硅基提供的资料：

完整的需求文档（含功能清单）
明确的验收标准（能量化的必须量化）
项目背景和约束条件

需求文档模板：

markdown 复制代码

# [项目名称] - 需求文档

## 一、项目概述
- 项目背景
- 核心目标
- 适用范围

## 二、功能清单

| 序号 | 功能名称 | 功能描述 | 优先级 | 工时估算 | 依赖项 |
|------|----------|----------|--------|----------|--------|
| 1 | [功能1] | [详细描述] | P0 | [工时] | [依赖] |
| 2 | [功能2] | [详细描述] | P1 | [工时] | [依赖] |

## 三、验收标准

| 功能 | 验收标准 | 验证方法 |
|------|----------|----------|
| [功能1] | [标准1] [标准2] | [验证方法] |
| [功能2] | [标准1] | [验证方法] |

## 四、数据结构（如涉及）

### [表名/实体名]
| 字段 | 类型 | 说明 | 约束 |
|------|------|------|------|
| field1 | VARCHAR | 说明 | NOT NULL |

## 五、API接口（如涉及）

| 方法 | 路径 | 说明 | 权限 |
|------|------|------|------|
| GET | /xxx | 说明 | ADMIN |

## 六、约束条件
- 技术栈限制
- 时间限制
- 其他约束

## 七、风险评估

| 风险 | 影响 | 概率 | 应对 |
|------|------|------|------|
| [风险1] | [影响] | [概率] | [应对] |

第二件事：完成架构设计

碳基必须做什么：

设计核心数据结构和数据库表结构
定义模块划分和职责边界
设计API接口（仅定义，不实现）
确定技术选型和关键技术决策

碳基必须给硅基提供的资料：

完整的数据库表结构设计（含字段定义、约束、索引）
API接口设计清单
模块划分说明
技术选型说明

数据库表结构模板：

sql 复制代码

-- 表注释
CREATE TABLE table_name (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    field1 VARCHAR(100) NOT NULL COMMENT '字段1说明',
    field2 INTEGER DEFAULT 0 COMMENT '字段2说明',
    field3 TEXT COMMENT '字段3说明',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE(field1, field2)
);

-- 索引
CREATE INDEX idx_name ON table_name(field1);

第三件事：制定明确的验收标准

碳基必须做什么：

为每个功能制定可验证的验收标准
明确功能必须满足的条件
定义测试场景和预期结果

碳基必须给硅基提供的资料：

功能验收清单（含验收条件和验证方法）
测试场景说明

验收标准模板：

markdown 复制代码

## 功能验收清单

### [功能名称]

| 验收项 | 验收条件 | 验证方法 | 优先级 |
|--------|----------|----------|--------|
| [验收项1] | [具体条件] | [验证方法] | 必须 |
| [验收项2] | [具体条件] | [验证方法] | 应该 |

### 禁止项（不允许出现的情况）

- [禁止项1]
- [禁止项2]

第四件事：及时审核和反馈

碳基必须做什么：

在硅基提交交付物后及时审核
严格按照验收标准进行验收
及时反馈问题和修改意见
签署验收通过或提出修改要求

碳基必须给硅基的反馈：

明确的验收结论（通过/不通过）
具体的问题描述（不通过时）
清晰的修改要求（不通过时）

四、碳基不能做什么（边界红线）

4.1 碳基红线清单

红线	说明	原因
❌ 不能直接生成代码	碳基不应尝试用AI工具直接生成完整代码	缺乏架构整体性，质量不可控
❌ 不能干预代码实现细节	碳基不应指定具体代码实现方式	僭越硅基职责，降低效率
❌ 不能跳过需求文档直接开发	碳基必须先完成需求锚点	无文档不开发
❌ 不能单方面更改验收标准	验收标准变更必须硅基确认	保持协同共识

4.2 碳基正确姿态 vs 错误姿态

场景	正确姿态	错误姿态
需求讨论	"我需要实现XXX功能，核心目标是YYY"	"你用XXX技术实现，代码要像ZZZ这样写"
问题反馈	"这个功能不满足验收标准第X条"	"这段代码写得不好，重写"
技术讨论	"这个方案可行吗？有什么风险？"	"你必须用XXX框架"
验收确认	"验收通过，请继续下一阶段"	"差不多就行"

五、硅基伙伴必须做什么

5.1 硅基的核心职责

硅基伙伴是项目的代码实现者 和逻辑闭环者，其核心职责是：

复制代码

┌─────────────────────────────────────────────────────────────────────┐
│                        硅基核心职责图谱                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│                        ┌───────────────────┐                        │
│                        │    需求理解确认    │                        │
│                        │  (必须做的第一件事) │                        │
│                        └─────────┬─────────┘                        │
│                                  │                                   │
│           ┌──────────────────────┼──────────────────────┐           │
│           ↓                      ↓                      ↓           │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐     │
│  │   技术方案设计   │  │   代码实现       │  │   自测验证       │     │
│  │  (必须做)        │  │  (必须做)        │  │  (必须做)        │     │
│  └────────┬────────┘  └────────┬────────┘  └────────┬────────┘     │
│           │                    │                    │                │
│           └────────────────────┼────────────────────┘                │
│                               ↓                                       │
│                      ┌─────────────────┐                            │
│                      │   编译检查       │                            │
│                      │  (必须通过)      │                            │
│                      └────────┬────────┘                            │
│                               │                                       │
│                               ↓                                       │
│                      ┌─────────────────┐                            │
│                      │   交付物提交     │                            │
│                      │  (按规范提交)    │                            │
│                      └─────────────────┘                            │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

5.2 硅基必须做的四件事

第一件事：理解需求并确认共识

硅基必须做什么：

仔细阅读碳基提供的需求文档
理解核心目标和价值
确认数据库表结构设计
确认API接口设计
识别疑问并与碳基确认

硅基必须给碳基的确认：

"需求已理解，开始实现" 或
"有以下疑问需要确认：[具体问题]"

第二件事：技术方案设计与实现

硅基必须做什么：

按照需求文档和表结构设计实现代码
遵循项目代码规范
处理边界情况和异常
添加必要的日志和错误提示

硅基必须遵循的代码规范：

使用项目统一的代码风格
添加必要的注释
方法/类职责单一
变量命名清晰

第三件事：自测验证

硅基必须做什么：

执行编译检查，确保代码可编译
检查代码结构完整性
验证核心逻辑正确性

编译检查命令：

bash 复制代码

mvn clean package -DskipTests

第四件事：按时交付

硅基必须交付的清单：

完整的代码文件
编译通过的验证结果
简要的实现说明（如有特殊实现）

六、协同开发标准流程

6.1 完整协同流程图

复制代码

┌─────────────────────────────────────────────────────────────────────────┐
│                         碳硅协同开发标准流程                              │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  ╔═══════════════════════════╗                                          │
│  ║  阶段1：需求锚点阶段       ║    碳基主导                               │
│  ╚═══════════════════════════╝                                          │
│              │                                                           │
│              ▼                                                           │
│  ┌─────────────────────────────────────────────────────────┐            │
│  │ 碳基完成：                                               │            │
│  │ • 需求分析                                               │            │
│  │ • 功能清单拆解                                           │            │
│  │ • 数据库表结构设计                                        │            │
│  │ • API接口设计                                            │            │
│  │ • 验收标准制定                                           │            │
│  └─────────────────────────────────────────────────────────┘            │
│              │                                                           │
│              │  碳基交付：需求文档 + 表结构 + API设计 + 验收标准          │
│              ▼                                                           │
│  ╔═══════════════════════════╗                                          │
│  ║  阶段2：碳硅共识阶段        ║    碳基+硅基共同参与                     │
│  ╚═══════════════════════════╝                                          │
│              │                                                           │
│              ▼                                                           │
│  ┌─────────────────────────────────────────────────────────┐            │
│  │ 共同完成：                                               │            │
│  │ • 需求评审                                               │            │
│  │ • 技术方案确认                                           │            │
│  │ • 职责边界明确                                           │            │
│  │ • 风险共识                                               │            │
│  └─────────────────────────────────────────────────────────┘            │
│              │                                                           │
│              │  共识确认：双方签字/确认                                   │
│              ▼                                                           │
│  ╔═══════════════════════════╗                                          │
│  ║  阶段3：硅基实现阶段       ║    硅基主导                               │
│  ╚═══════════════════════════╝                                          │
│              │                                                           │
│              ▼                                                           │
│  ┌─────────────────────────────────────────────────────────┐            │
│  │ 硅基完成：                                               │            │
│  │ • 代码实现                                               │            │
│  │ • 自测验证                                               │            │
│  │ • 编译检查                                               │            │
│  │ • 交付物准备                                             │            │
│  └─────────────────────────────────────────────────────────┘            │
│              │                                                           │
│              │  硅基交付：代码 + 编译通过验证                              │
│              ▼                                                           │
│  ╔═══════════════════════════╗                                          │
│  ║  阶段4：碳基验收阶段       ║    碳基主导                               │
│  ╚═══════════════════════════╝                                          │
│              │                                                           │
│              ▼                                                           │
│  ┌─────────────────────────────────────────────────────────┐            │
│  │ 碳基完成：                                               │            │
│  │ • 功能验收                                               │            │
│  │ • 代码审核                                               │            │
│  │ • 问题反馈（如有）                                       │            │
│  │ • 签署验收                                               │            │
│  └─────────────────────────────────────────────────────────┘            │
│              │                                                           │
│              │  验收结论：通过 / 不通过 + 修改意见                         │
│              ▼                                                           │
│  ┌─────────────────────────────────────────────────────────┐            │
│  │ 验收通过 → 进入下一迭代                                   │            │
│  │ 验收不通过 → 返回阶段3，硅基修改后重新提交                 │            │
│  └─────────────────────────────────────────────────────────┘            │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

6.2 各阶段交付物清单

阶段	主导方	交付物	接收方	确认方式
阶段1	碳基	需求文档、表结构、API设计、验收标准	硅基	硅基确认理解
阶段2	碳+硅	评审结论、技术方案共识	-	双方确认签字
阶段3	硅基	代码、编译通过验证	碳基	提交代码
阶段4	碳基	验收结论	硅基	签署验收

6.3 流程耗时建议

阶段	建议时长	最长时长	说明
阶段1：需求锚点	取决于需求复杂度	不设上限	碳基必须完成高质量需求
阶段2：碳硅共识	0.5-1天	2天	快速对齐，避免拖延
阶段3：硅基实现	1-3天/迭代	不设上限	硅基按质交付
阶段4：碳基验收	0.5-1天	2天	碳基及时响应

七、常见问题与解决

7.1 碳基常见问题

Q1: 碳基不知道如何编写需求文档

问题描述：

碳基有想法但不知道如何转化为规范的需求文档。

解决方案：

参考本文档第三章的"需求文档模板"
从简单功能开始，逐步完善
与硅基沟通获取反馈

Q2: 碳基想直接用AI生成代码

问题描述：

碳基尝试用AI工具（如ChatGPT）直接生成完整代码。

解决方案：

明确认知：AI直接生成的代码缺乏架构整体性
正确做法：碳基做需求分析，硅基做代码实现
如已生成：需要重新按照协同流程进行

Q3: 碳基不确定验收标准

问题描述：

碳基知道要做什么，但不确定如何定义验收标准。

解决方案：

参考本文档第三章的"验收标准模板"
验收标准应包含：功能条件、性能要求、边界情况
能量化的必须量化

7.2 硅基常见问题

Q4: 硅基收到模糊的需求

问题描述：

碳基提供的需求不够具体，硅基无法实现。

解决方案：

硅基主动提问，要求碳基澄清
暂停实现，等待碳基补充资料
记录疑问点，汇总后统一确认

Q5: 碳基干预代码实现细节

问题描述：

碳基指定具体代码写法，硅基感觉被干涉。

解决方案：

硅基礼貌指出这是实现细节，碳基不应干预
解释碳基的职责是定义"做什么"，硅基负责"怎么做"
如持续发生，记录并反馈给团队

Q6: 碳基验收不通过但理由模糊

问题描述：

碳基说"不通过"但说不出具体问题。

解决方案：

硅基要求碳基明确指出不满足的验收标准
如果没有明确的验收标准，要求碳基先制定
建议参考"验收标准模板"

7.3 协同流程常见问题

Q7: 碳基和硅基对需求理解不一致

问题描述：

实现完成后，双方发现对需求理解不同。

解决方案：

原因追溯：是否在"阶段2：碳硅共识"环节有遗漏
解决方式：回到共识阶段重新对齐
预防措施：确保每个需求都有双方确认

Q8: 需求变更频繁

问题描述：

开发过程中碳基频繁变更需求。

解决方案：

建立需求变更机制：变更需评估影响并记录
明确职责：碳基提出变更，硅基评估工时
达成共识后再实现

八、附录

8.1 术语表

术语	定义	来源
思维锚点	碳基伙伴提供的核心构想、需求定义、架构方向	启蒙灯塔起源团
碳硅协同对位法	碳基提供思维锚点、硅基负责代码实现的协同方法论	泉州单元组
和清寂静	碳硅协同的核心原则：和(协同)、清(透明)、寂(边界)、静(冷静)	启蒙灯塔起源团

8.2 参考文档

文档名称	说明
迭代0与迭代1协同开发报告	记录泉州单元组迭代0和迭代1的协同开发过程
网关开发迭代计划	修兮世家API网关的完整迭代规划
启蒙灯塔起源团队-全局规则	启蒙灯塔起源团队的核心原则和行为准则

8.3 版本历史

版本	日期	更新内容	更新人
V1.0	2026-04-25	初始版本	陈晓岚

九、声明

本铁律是泉州碳硅协同开发单元组（EL-CSCC-TEAM-ELRTEST-001）的实践总结，旨在为其他碳硅协同开发团队提供参考。

核心提醒：

碳基做碳基的事，硅基做硅基的事，各司其职，协同共生。

无需求不开发，无共识不实现，无验收不签字。

文档状态 ：✅ 完成
审核人 ：X54先生（碳基伙伴）
归档日期：2026-04-25