从经营到系统：基于本源哲学六原则的软件研发与 AI 辅助开发框架探索
一、先把“系统存在的前提”说透：经营与系统谁先谁后？
系统不是经营的起点，而是经营的“固化器 + 放大器”。
先有经营与实践：否则需求只能来自设想而非现实，系统极易演化为脱离现场的“自嗨式工程（building in a vacuum，脱离实际业务环境）”。
再有系统化：只有当业务已经通过试运行、手工台账、SOP、看板、审批流等方式跑通基本闭环，系统建设才拥有清晰、稳定、可固化的对象。
即便是所谓的“平台型基础设施（platform infrastructure）”或“合规刚需系统（compliance requirement）”，其开发同样并非脱离经营与实践的例外情形。平台之所以需要被建设，本身就源于明确或可预期的经营需求与责任约束，例如业务规模扩展、组织协作复杂化、合规与审计要求、风险控制边界等。
因此，即使在平台型系统中可以先行构建最小可用版本（Minimum Viable Product，最小可用产品），这一底座的边界设定、数据模型与演进方向，也必须建立在真实业务数据与真实角色之上，而不是抽象假设或技术偏好之上。这一判断在软件工程的主流标准中同样成立：软件生命周期过程强调从概念形成、需求澄清、设计实现到运行与退役的完整闭环，而不是以编码作为起点。以 ISO/IEC/IEEE 12207 为代表的软件生命周期标准，正是为此提供了系统化、可治理的通用框架。
二、参考国际标准：把“研发标准流程”转变为可执行的版本
我们可以把通用的软件研发流程（无论瀑布、敏捷、DevOps）抽象成 6 个关键产物（deliverables，交付物），并用标准来做“底线对齐”：
- 业务与目标定义（Business/Mission Analysis，业务/使命分析）
- 需求工程（Requirements Engineering，需求工程）
- 架构与方案设计（Architecture & Design，架构与设计）
- 实现与验证（Implementation & Verification，实现与验证）
- 发布与运维（Release & Operations，发布与运维）
- 持续改进与退役（Continuous Improvement & Retirement，持续改进与退役）
其中“需求工程”的标准化最值得你重点对齐：ISO/IEC/IEEE 29148 明确了需求工程过程与信息项（information items，信息项/文档要素）的要求，其实就是本源哲学六原则在“明本阶段”的硬标准。 ISO/IEC/IEEE 12207 则提供更全的生命周期过程框架，便于把系统模块放进统一生命周期治理。
三、如何采用本源哲学六原则管控系统开发全流程
下面是本源哲学六原则系统研发方法（OntoLean SDLC）”。每一条都给出要问的问题 + 必备产物 + 验收口径。
1) 明本（Clarity of Ontology，本源清晰）：把“系统为什么存在”写成可验收的事实
关键问句
- 为谁服务（primary users，主要用户）？谁付钱（buyer，付费方）？谁受影响（stakeholders，利益相关者）？
- 这个系统要解决的“第一痛点”（primary pain point，主要痛点）是什么？
- 不做系统时，用 SOP/表格能否跑通？瓶颈在哪里（constraint，约束/瓶颈）？
必备产物（建议你做成模板）
- 《问题定义与价值假设》：目标、边界、成功指标（success metrics，成功指标）
- 《角色与场景清单》：角色—任务—频次—风险
- 《收益/成本/价格模型草案》：至少包含可变成本、交付成本、维护成本的口径
验收口径
- 需求不允许以“功能列表”开头，必须以“问题—场景—价值—指标”开头。
- 未能写清“成功指标”的需求，一律不得进入开发排期。
对应标准：12207 强调生命周期过程框架；29148 强调需求工程信息项与过程要求。
2) 正衡（Integrity of Balance，守正与平衡）：把“短期可交付”和“长期可演进”同时算清
关键问句
- MVP（Minimum Viable Product，最小可用产品）做哪些？明确“不做清单”（non-goals，不做目标）。
- 数据一致性、权限边界、审计追溯（traceability，可追溯）与交付速度怎么平衡？
- 单体/模块化/微服务如何选型？（不要为了“先进”而先进）
必备产物
- 《范围与里程碑》：MVP、V1、V2 的拆分
- 《架构决策记录 ADR》（Architecture Decision Record，架构决策记录）：每个关键选型写清取舍
验收口径
- 每个模块必须有“演进路线”，否则视为一次性工程。
- 每个关键取舍必须留下 ADR，避免团队靠记忆决策。
3) 知止（Boundary of Action，边界与止损）：把“停的规则”写进流程与代码
关键问句
- 哪些需求会导致范围蔓延（scope creep，范围膨胀）？触发条件是什么？
- 哪些风险到阈值必须停（stop rule，停止规则）？
- 什么时候应该删功能而不是加功能？
必备产物
- 《验收标准与退出条件》：每个里程碑都要有“通过/不通过”规则
- 《风险清单与阈值》：安全、数据、合规、成本、进度
验收口径
- 没有退出条件的项目=不可控项目。
- 发布必须有回滚（rollback，回滚）预案。
4) 致精（Essential Focus，聚焦与精进）：用“质量系统”保证可持续交付
关键问句
- 关键链路（critical path，关键路径）是什么？先把它做到极致。
- 哪些指标能持续度量质量：缺陷率、交付周期、回归成本、性能基线？
必备产物
- 测试策略（test strategy，测试策略）：单测/集成/回归
- 代码规范与审查规则（code review checklist，审查清单）
验收口径
- 任何“赶工”都必须以“测试与回滚能力不降级”为底线。
- 建议把“可观测性”（observability，可观测性：日志/指标/追踪）纳入 Definition of Done（完成定义）。
5) 利众（Shared Benefit，共益）：把“可用、好用、敢用”做成产品能力
关键问句
- 系统使用方，比如一线员工最怕什么：多录、重复、背锅、审批慢？
- 经营者最需要什么：看得懂、可追责、可复核（auditability，可复核）？
- 业主/投资人最关心什么：证据链、口径一致、风险暴露？
必备产物
- 角色化界面与权限矩阵（RBAC，基于角色的访问控制）
- 培训与落地包：SOP、操作卡片、异常处理手册
验收口径
- “不用培训就能完成关键任务”的比例要被度量。
- 每条关键数据必须能追溯来源（谁在何时以何依据录入/导入/计算）。
6) 创新（Innovation，守正出新）：AI 不是“外挂”，而是“研发流程里的新工种”
关键问句
- AI 适合替代/增强哪些环节：需求澄清、代码生成、测试生成、重构、迁移、文档、审查？
- 如何降低“幻觉”（hallucination，编造）与安全风险？
- 如何把 AI 产出纳入审计与评审？
必备产物
- 《AI 使用规范》：允许/禁止场景、敏感信息处理、模型输出验收规则
- 《上下文工程（context engineering，上下文工程）》规范：让 AI 在正确材料上工作
验收口径
- AI 生成代码必须经过同等 Code Review 与测试门槛。
- AI 访问仓库、终端、凭据必须分级授权。
四、把 AI 嵌入开发：VS Code Copilot / Agent Mode 与 Qoder 的“真实价值点”
1) Copilot Agent Mode 的价值：从“补全”走向“多步任务执行”
在 VS Code / Visual Studio 体系里，Copilot 的 Agent Mode 被定义为可执行多步骤任务：读取相关文件、提出修改、运行终端命令与测试，并在错误出现后迭代修复。
这对多模块系统（采购/收货/能源/人力/权限/看板）尤其有用，典型场景：
- 重构（refactor，重构）：批量迁移命名规范、API 前缀、公共组件抽取
- 单元测试补齐：对关键计算口径（金额、比例、汇总）生成测试用例
- 迁移与现代化（modernization，现代化改造）：微软也在推动“app modernization agent”类能力，用于升级与迁移。
2) Qoder 的定位：更偏“代码库理解 + 任务型智能体平台”
Qoder 将自己定位为 agentic coding platform（智能体式编码平台），强调“让代码库对人和 AI 都更可理解”，以降低幻觉并提升对齐。 对体系化研发而言，它更像是把“架构理解（architecture understanding，架构理解）”与“上下文工程”产品化的一类工具路线。
实操建议（不依赖某一家工具）：
我们要固化的不是“某个 AI 工具”，而是AI 在流程中扮演的岗位：
- 需求秘书：把会议/聊天整理为需求条目与澄清问题
- 架构助理：生成 ADR 草案、影响分析
- 测试助理：生成回归用例与边界用例
- 文档助理：让“代码即文档”真正落地
3) 必须正视的风险：AI IDE 的系统级安全隐患
近年来的安全研究指出，AI 辅助开发工具在与 IDE 深度集成后，已不再局限于“代码建议”，而是逐步具备文件访问、上下文推理与命令执行等能力。在此背景下，提示注入（Prompt Injection）、敏感信息外泄以及间接远程代码执行等风险被系统性提出。部分安全研究将这一类风险统称为 “IDEsaster”（IDE + disaster），用以描述 AI 编码智能体在高权限开发环境中可能引发的系统性安全后果。
因此，在 AI 深度参与研发活动的背景下，“知止”原则必须被具体化为可执行的工程约束：工具权限分级、终端命令白名单、敏感信息隔离，以及完整的审计与留痕机制。
五、让“各经营单位更方便用到差异化系统”：产品化与平台化的落地路径
关于如何让企业在不同组织、不同企业、不同项目上，快速得到“差异化但可维护”的系统。建议走三层结构：
A. 平台层（Platform，平台）
- 多租户（multi-tenant，多租户）/多公司隔离
- 统一身份与权限（RBAC）
- 统一审计与追溯（traceability/auditability）
- 统一数据字典与指标口径（metrics catalog，指标目录）
B. 领域模块层（Domain Modules，领域模块）
采购、收货、能源、人力、财务、审批、经营分析等模块做成可插拔（plug-in，可插拔），并有安装器（installer）与默认权限/菜单初始化——这与你已确立的 installer 目录标准完全一致。
C. 配置与差异层（Configuration，配置层）
真正的“差异化”尽量通过配置完成，而不是分叉代码：
- 表单配置、字段映射、审批流配置、报表口径配置
- 特性开关（feature flag，特性开关）控制客户差异
- 模板库：按行业/酒店类型/组织结构提供预置方案
用六原则来约束这条路：
- 明本：每个差异必须对应真实经营差异与价值
- 正衡：差异不破坏平台一致性
- 知止：禁止为单一客户做不可回收的“硬分叉”
- 致精：把高频差异沉淀成可复用配置模板
- 利众：让一线更省事、让管理层更透明
- 创新：用 AI 把“配置生成、字段映射、脚本生成、数据校验规则生成”自动化
六、可直接落地的研发检查清单（评审表建议）
立项评审（对应：明本 / 利众 / 知止）
- 目标用户、使用角色与付费方是否清晰区分并已确认？
- 系统成功的判定指标是否可量化、可验证、可复核？
- 是否已明确“不做清单”与阶段性退出条件，以防止范围失控？
方案评审（对应：正衡 / 知止 / 创新）
- 关键架构与设计取舍是否通过 ADR（Architecture Decision Record，架构决策记录）完整留痕？
- 是否具备可执行的回滚与降级方案，以应对失败或不确定性？
- AI 的引入是否在不触碰敏感数据与核心机密的前提下，明确实现了效率或质量的可衡量提升？
交付评审（对应：致精 / 利众）
- 核心业务链路是否具备稳定、可重复的自动化测试与回归机制？
- 关键指标与数据口径是否在系统内保持一致，并具备完整的追溯能力？
- 一线使用路径是否足够简洁，做到“少录入、少跳转、少解释”，从而降低操作与协同成本？
研发团队的统一判断口径
先经营，后系统；先明本，后编码。
系统并非目的本身，而是将已经被验证的经营规律与实践经验，
固化为可追溯、可复核、可复用的组织能力，
以支撑更稳定的协作、更清晰的责任划分，以及更长期的价值创造。