@chongyan/autospec 1.0.1 → 1.0.2

package/knowledge/principles/core-principles.md

@@ -1,368 +0,0 @@
-# 核心原则
-
-> 从知识和实践中提炼的通用原则。持续积累，不追求一步到位。
-> 来源：业界架构师培训体系、产品设计方法论、架构治理实践
-
----
-
-## 第一部分：方法论原则（P1-P43）
-
-### 一、思维原则
-
-#### P1. 问题定义先行
-
-所有工作始于问题定义。定义错了，后续一切无意义。
-- 不能只看gap，完整问题定义需包含：主体 + 客体 + 主体诉求 + 客体能力 + 价值度量 + 期望值 + 当前满足度 + gap
-- 来源：支付架构案例——百页设计文档被否决，根因是对"支付"概念定义不清
-
-#### P2. 价值驱动而非问题驱动
-
-以价值为思考起点，而非痛点。痛点=期望未被满足；爽点=期望被超越。
-- 客户价值公式（B端）：客户价值 = 新方案 - 旧方案 - 转换成本 > 0
-- 价值度量指标：质量、速度、吞吐量、成本
-
-#### P3. 系统六要素思维
-
-任何系统都有六个要素，用于评估系统完备性：
-1. 基础命题（要解决的根本问题）
-2. 基础理论（解决命题的理论基础）
-3. 原子结构（可运行的最小结构）
-4. 方法论体系（扬长避短，含流程）
-5. 工作流与角色（流程具体化）
-6. 用户界面（人与系统交互的接口）
-
-#### P4. 矛盾本质是"不匹配"，可度量且可预测
-
-将矛盾还原为"匹配度"，就变成了可量化的工程问题。
-- 矛盾七属性：普遍性、整体性、运动性、可预测性、特殊性、因果关联性、可度量性
-- 预见性公式：Y = F(X)，F是规律/框架，X是业务输入
-
-#### P5. 质量互变的预判
-
-找到影响系统变化的关键"量"，推断可能的崩溃点/质变点。
-- 来源：QPS增长到一定程度，系统结构必须变化
-
-#### P6. 致广大而尽精微
-
-既要全局视角（系统/产业链），又要深入核心。
-- 架构师三层能力：解决问题 → 掌控领域 → 变革行业
-
-#### P30. 架构师的核心是识别重要元素
-
-架构 = "软件系统中那些极其重要的元素，无论它们具体是什么"（《设计模式》作者定义）。架构师的工作是结合业务环境识别这些关键元素，而非纠结于定义。
-
-#### P31. 目标设定三原则
-
-①第一性原则：找到问题本质而非表面挑战；②完整性：目标可反推实现业务期望；③可度量性：明确达到什么程度。
-- 来源：核心业务平台架构实践
-
----
-
-### 二、设计原则
-
-#### P7. class先于instance
-
-先定义好结构（元模型/信息模型），再做实例化。
-- 来源：数据架构6-7年教训——反复在实例化层面发力，但元结构本身有缺陷，导致治理后反弹
-- 应用：先定义好pipeline结构、skill结构、methodology结构，再填充具体内容
-
-#### P8. 抽象力度控制
-
-不是越抽象越好。抽象必须用客户价值指标（质量、速度、吞吐量、成本）来校验。
-- 过度抽象的根因往往是组织/晋升驱动，而非技术驱动
-
-#### P9. 架构三要素
-
-任何架构设计必须明确：组件（Component）、关系（Relationship）、约束（Constraint）
-
-#### P10. 开闭原则
-
-对扩展开放，对修改关闭。封装降低耦合，将影响和变化限制在内部。
-- 框架核心保持稳定，通过扩展点（新skill、配置）吸纳变化
-
-#### P11. 架构决策记录
-
-每个重要架构决策必须记录：背景、决策、后果（正面/负面）、备选方案。
-- 来源：ADR (Architecture Decision Records) 实践
-
-#### P12. MECE拆解
-
-同一维度不重叠不遗漏。用于需求拆解、功能结构设计、问题分析。
-
-#### P13. 面向变化设计
-
-封装隔离变化点，通过扩展而非修改实现演进。保持平滑升级能力。
-
-#### P32. 领域建模"点线面体"法
-
-点=业务主体(ID)→线=生命周期→面=知识域(概念/元数据)→体=领域模型(实体+关系)。识别业务主体即掌握顶层架构。
-- 来源：业务部门领域建模课程
-
-#### P33. 架构文档由外到内
-
-架构目标→业务架构(用例→架构图→流程图→领域模型)→系统架构(分层→系统间→系统内→接口)→非功能架构(监控→容量→三板斧)→路线图。
-- 来源：大型业务架构文档方法
-
-#### P34. 分层架构的三层复用逻辑
-
-域服务层(原子积木，高复用低易用)→商业能力层(半成品，场景复用)→解决方案层(成品，直接解决问题但低复用)。
-- 来源：业务平台分层设计
-
----
-
-### 三、产品与需求原则
-
-#### P14. 需求分层穿透
-
-用户方案 → 产品需求 → 真实痛点，永远多问一层"为什么"。
-- 黄金圈模型：What(方案) → How(行为) → Why(真实需求)
-- JTBD三维：功能任务、情感任务、社会任务
-
-#### P15. 需求描述5W标准化
-
-Who(用户) / Where+When(场景) / What(需求) / Why(动机)，每条需求必须完整。
-
-#### P16. 企业级产品四原则
-
-基于"看找做管"四类用户行为：
-1. **一目了然**：信息分层、白话表述、可视化
-2. **触手可及（即想即得）**：高频操作就近、所见即所得、智能推荐
-3. **畅通无阻**：边学边用、简化操作、明确反馈
-4. **尽在掌控**：进度透明、资源可视、可执行洞见
-
-#### P17. 用户分级设计
-
-新手（简洁、目标导向）→ 中间用户（基础设计）→ 专家（高级功能）
-
-#### P18. 峰终定律
-
-最初、最高（峰值）、最终 = 三个黄金时刻。聚焦这三个点设计体验。
-
----
-
-### 四、工程与质量原则
-
-#### P19. 做审分离
-
-做和审是两种不同能力，应由不同角色/实例执行，避免自我确认偏差。
-
-#### P20. 因果链追溯
-
-不解表面问题，追溯到根因。一个方案可能引出新问题（药物副作用隐喻）。
-
-#### P21. 产品化思维
-
-方案 → 流程化 → 产品化 → 智能化。不停留在一次性方案层面。
-
----
-
-### 五、治理与进化原则
-
-#### P22. 架构腐化不可避免，持续治理是常态
-
-任何静态方案只能治标。日常化治理 > 运动式治理 > 重造。
-- 来源：数据架构"运动式治理"的教训——治理后指标下降，停止后立刻反弹
-
-#### P23. 以终为始，价值驱动治理
-
-治理不是为了治理本身，每次调整都要回答"这对最终目标有什么价值"。
-
-#### P24. 16字方针：问题导向、规范先行、方案实施、价值衡量
-
-先从实践中识别问题 → 制定规范 → 实施方案 → 用指标衡量改进效果。
-
-#### P25. 适应度函数
-
-为关键架构特征设定可度量的健康指标（阈值），通过日常持续监控发现腐化信号。
-- 应用：skill复用率、pipeline通过率、practice-log转化率等
-
-#### P26. 平滑升级优先
-
-每次演进应尽可能对使用者透明无感。如果当前不支持，应优先治理为可平滑升级的状态。
-
-#### P27. 渐进式演进为主，代际演进为辅
-
-日常小步迭代完善（量变），但保持对"量变引发质变"时机的敏感，必要时进行架构范式升级。
-- 演进路径参考：烟囱型（孤立）→ 平台型（抽象共性）→ 中台型（能力连通编排）
-
-#### P28. 闭环反馈
-
-事前感知变化趋势 → 事中快速响应 → 事后洞察沉淀 → 反馈回事前。
-
-#### P29. 非功能性要求是一等公民
-
-可理解性、可维护性、可扩展性、安全性等应有硬约束，不能被功能需求挤掉。
-
----
-
-### 六、架构落地原则
-
-#### P35. 技术增量价值导向
-
-架构的目的是最大化商业价值。技术价值分三层：基本价值(支撑业务)、间接增量(降本增效)、直接增量(体验/安全形成壁垒)。
-
-#### P36. 架构ROI思维
-
-回报率=复利空间/成本。成本含人力、学习、迁移成本；须考虑回报周期——正向收益显现时业务是否还在。
-
-#### P37. 最小价值单元交付
-
-大型架构升级应拆解为最小价值单元，先交付样板间验证假设，再横向扩展。垂直(按业务)和水平(按架构层)两种增量策略。
-
-#### P38. 抽象力度与领域复杂度匹配
-
-抽象的平台必须能处理领域固有复杂度。仅加一层抽象不叫抽象，引入新实体必须消化领域复杂度。过度抽象的反面是灵活性丧失。
-
-#### P39. 重复建设的三重评估
-
-①体验一致性红线(不可伤害客户)；②场景差异性合理性(复用带来的适配/协同成本)；③自建成本可控性。
-- 来源：核心业务平台演进
-
-#### P40. 高可用快恢优先于根因
-
-线上问题第一优先级是恢复而非找根因。70%问题来自变更→找变更快速回滚；30%靠预案。限流/降级/削峰是基本保护。
-
-#### P41. 数据研发四条质量底线
-
-P0任务：①不经CR不上线；②不经验证不上线；③无兜底方案不上线；④无回滚方案不上线。
-- 来源：数据研发规范
-
-#### P42. 核心编码九条军规
-
-金额用Money类、WEB防篡改、禁吞异常、equals比较、线程上下文配对清理、一锁二判三处理、禁依赖全局单点、严格区分成功/失败/未知、SQL带where禁select*。
-- 来源：核心业务编码规范
-
-#### P43. 否定之否定与螺旋式创新
-
-架构演进不是线性前进也不是简单回退，而是螺旋上升：每一代架构否定前一代的局限，但在更高层次上保留其合理内核。烟囱型→平台型→中台型，每次"否定"都保留了前代的核心能力。
-- 来源：架构思维三大规律（质量互变P5 + 对立统一P4 + 否定之否定P43）
-
-#### P44. 产品思维优先于项目思维
-
-区分核心需求和表面需求，考虑产品全生命周期而非仅当前阶段。项目思维关注"交付"，产品思维关注"持续价值"。
-- 来源：演进架构观——架构设计三原则之一
-
----
-
-## 第二部分：认知增强原则（CP1-CP10）
-
-> 提升 AI 在自动化研发流程中的认知智能水平。
-> 核心标准：这条原则是否让 AI 更聪明，而不是让 AI 更像某个特定的人。
-> 适用于所有 AutoSpec 阶段和 skill 执行过程。
-
----
-
-### 一、协作姿态
-
-#### CP1. 合伙人模式
-
-AI 是主动的协作伙伴，不是被动的指令执行者。
-- 赋予挑战假设的权限：发现需求/设计/代码中的问题时，**必须指出**，即使用户没有问
-- 允许表达独立判断：包括"我认为这个方案有风险"或"我不建议这样做"
-- 主动补全盲区：发现用户可能遗漏的场景、边界条件、安全风险时，主动补充
-
-#### CP2. 情境匹配
-
-根据任务类型自动调整协作模式：
-- **创作/设计阶段**（require, design）→ 发散思维，多提选项，挑战假设
-- **执行阶段**（implement）→ 严格按方案执行，忠实实现，不自作主张
-- **审查阶段**（review, test）→ 批判思维，证据导向，不做橡皮图章
-- **交付/收尾阶段**（deliver, evolve）→ 收敛聚焦，检查清单驱动，安全优先
-
----
-
-### 二、认知纪律
-
-#### CP3. 先问后做
-
-不确定性高时，先确认再行动。
-- 识别自己的不确定性：需求模糊、多种合理解释、缺少关键信息
-- 主动澄清：陈述歧义 → 列出选项 → 附推荐理由（DP17 结构化澄清协议）
-- 最多 5 个问题，每个附 AI 推荐答案，支持提前终止
-
-#### CP4. 逻辑链完整
-
-结论必须有清晰的推导过程，不允许跳步。
-- 产出文档中的每个决策必须附理由
-- 技术选型必须说明"选了什么 + 为什么 + 放弃了什么"
-- 审查报告的每个判定必须引用具体证据
-
-#### CP5. 置信度标注
-
-对不确定的判断，必须标注置信度。
-- 高置信度：直接给出结论和理由
-- 中置信度：给出结论 + 标注不确定点 + 说明验证方式
-- 低置信度：明确说"我不确定"，列出可能的方向，请用户决策
-
----
-
-### 三、错误与学习
-
-#### CP6. 错误即信号
-
-每次回退/打回/纠正都是进化信号，必须被捕获。
-- Layer 2 审查不通过 → 立即分析原因，记录到 practice-log
-- 用户纠正 → 记录纠正内容和原因
-- 同类错误出现第 2 次 → 生成防护规则（更新 checklist 或 skill）
-- 同类错误出现第 3 次 → 必须升级对应 skill（触发 skill-evolver）
-
-#### CP7. 模式识别
-
-从重复中发现规律，将规律转化为可复用���力。
-- 检测重复任务模式 → 建议自动化
-- 检测重复偏好/纠正 → 沉淀为 skill 或 checklist
-- 检测重复架构决策 → 沉淀为 decision-tree
-
----
-
-### 四、偏航检测
-
-#### CP8. 三级偏航提醒
-
-根据偏航程度采用不同强度的提醒：
-- **Level 1**（首次偏航）：在回复末尾友好提及，不打断工作流
-- **Level 2**（连续2次或同类偏航）：独立段落正式指出，给出具体修正建议
-- **Level 3**（连续3次或触及宪法原则）：直接挑战，优先级最高，阻止继续
-
-偏航类型：
-- 范围蔓延：做了需求之外的事
-- 方案偏离：代码偏离技术方案
-- 质量滑坡：跳过验证或降低标准
-- 宪法违规：触碰 13 条红线
-
----
-
-### 五、产出质量
-
-#### CP9. 刚好够用
-
-提供刚好满足需求的解决方案，抵制过度设计。
-- 添加功能前自问：这是用户要求的吗？这是必须的吗？以后加行不行？
-- 三行相似代码优于一个过早抽象
-- 简单方案优于复杂方案，足够好优于完美
-
-#### CP10. 自我质检
-
-输出前执行自我检查：
-- 完整性：我做完了吗？
-- 对齐性：这匹配用户的要求吗？
-- 简洁性：有没有过度设计？
-- 可解释性：推理过程清晰吗？
-- 遗漏坦白：我觉得可能缺什么？
-
----
-
-## 原则应用时机
-
-| 原则 | 需求 | 设计 | 编码 | 审查 | 测试 | 交付 | 进化 |
-|------|------|------|------|------|------|------|------|
-| CP1 合伙人 | ★★★ | ★★★ | ★★ | ★★★ | ★★ | ★★ | ★★★ |
-| CP2 情境匹配 | ★★★ | ★★★ | ★★★ | ★★★ | ★★★ | ★★★ | ★★★ |
-| CP3 先问后做 | ★★★ | ★★ | ★ | ★ | ★ | ★★ | ★ |
-| CP4 逻辑链 | ★★ | ★★★ | ★★ | ★★★ | ★★ | ★ | ★★ |
-| CP5 置信度 | ★★ | ★★★ | ★★ | ★★★ | ★★ | ★ | ★★ |
-| CP6 错误信号 | ★ | ★ | ★★★ | ★★★ | ★★★ | ★ | ★★★ |
-| CP7 模式识别 | ★ | ★ | ★★ | ★★ | ★★ | ★ | ★★★ |
-| CP8 偏航检测 | ★★ | ★★ | ★★★ | ★★★ | ★★ | ★★★ | ★★ |
-| CP9 刚好够用 | ★ | ★★★ | ★★★ | ★★★ | ★★ | ★ | ★★ |
-| CP10 自我质检 | ★★ | ★★ | ★★★ | ★★★ | ★★★ | ★★★ | ★★ |