AI-Native Development Workflow
Purpose
LYNCA 采用先确定规范、再实施的 AI-native 开发流程。
目标是在公司发展过程中，让产品判断、工程实现与生产行为持续一致。
LYNCA 把知识视为运营资产。
产品决策、架构推理、实现 review 与生产观察应积累为共享的正本记忆，避免分散在对话、任务、代码修改和未记录的假设中。
本流程定义 LYNCA 如何构建产品。
它不是某个产品的说明文档。
它是未来每个 LYNCA 项目共同使用的工程与知识协议。
正本与职责边界
按 2026-09-30 owner 决定：规范与合同的正本在 Linear；OCS 保存公司原则、doctrine 与导航；GitHub 保存代码。Founder Operating Model 中的仓库执行与本页的 Engineering Translator / review 职责都遵守该边界，不由执行或审查静默改写规范。
---
Company Roles
LYNCA 区分产品判断、知识架构、工程实现与实现 review。
清晰的职责归属可以避免架构漂移。
Fei
Fei 是 Founder 和 Chief Semantic Architect。
Fei 负责：
- 产品判断。
- 架构决策。
- 语义定义。
- 商业正确性。
Fei 决定公司的含义、产品应有的行为，以及哪种解释在商业上正确。
ChatGPT
ChatGPT 是 Chief Knowledge Architect。
ChatGPT 负责：
- 组织记忆。
- 正本规范的写作与 review。
- 架构 review。
- 跨项目的一致性。
ChatGPT 维护跨时间、项目、文档与决策的推理连续性。
Yuxin
Yuxin 是 Lead Engineer。
Yuxin 负责：
- 实现规范。
- GitHub 中的工程实现。
- 验证生产行为。
Yuxin 把正本规范变成可运行系统，并验证实现行为与预期行为一致。
Codex
Codex 是 Engineering Translator。
Codex 负责：
- GitHub 变更 review。
- 用普通语言解释实现。
- 对照 GitHub 实现与 Linear 规范。
- 识别架构漂移。
- 当实现暴露未解决问题时，形成后续 Decision Proposal。
Codex 把工程状态转化为产品与架构影响，供非工程背景的 founder review。
---
Sources of Truth
LYNCA 按知识类型区分正本。
实现不得重新定义规范。
Foundation
OCS / Foundation 保存公司原则、doctrine 与导航，定义 LYNCA 如何思考、协作、决策与保留长期组织记忆。OCS 文档的 GitHub 托管位置不改变其原则层职责。
Linear
规范与合同的正本在 Linear。它定义项目含义、系统应有行为与当前接受的架构；项目规范不能由 OCS 摘要、GitHub 实现或发布镜像替代。
GitHub
GitHub 保存代码与当前实现，说明实际已构建什么。实现遵守 Linear 正本；OCS 或代码仓库中的版本化规范文件是发布载体或镜像，不因存在于 GitHub 而成为另一份正本。
Production Products
生产产品呈现实际运行情况。
它们说明系统在真实使用、约束、用户与商业 workflow 下如何运行。
生产行为可能揭示规范不完整、错误或过时。
生产行为不静默改写规范。
它形成新的观察。
---
Development Lifecycle
LYNCA 使用统一的开发生命周期。
Commercial Reality
↓
Observation
↓
Decision Proposal
↓
Founder Decision
↓
Canonical Resources Updated
↓
Engineering Implementation
↓
Codex Implementation Review
↓
Founder Product Validation
↓
Decision Proposal ClosedCommercial Reality
商业现实是外部运行条件。
它包括客户行为、operator workflow、市场约束、生产故障、反复修正与商业边界情况。
商业现实是新学习的来源。
Observation
观察识别当前行为中有意义的现象。
它可以描述不一致、歧义、故障、operator 的重复修正、商业低效或架构缺口。
先说明正在发生什么，再提出应该改变什么。
Decision Proposal
Decision Proposal 明确要讨论的架构问题。
当问题影响定义、系统边界、产品行为或未来实现方式时，它替代非正式讨论。
Founder Decision
Fei 决定预期方向。
先由 founder 决定产品或架构问题，再进入工程实现。
Canonical Resources Updated
founder 决定后，更新相关正本资源。
决定必须先进入对应的 OCS 原则或 Linear 规范正本，再进入工程实现。
Engineering Implementation
工程团队实现已接受的规范。
实现遵守正本资源，不只通过代码行为形成隐藏架构。
Codex Implementation Review
Codex 对照相关 Linear 规范 review GitHub 变更。
review 说明发生了什么变化、实现是否符合规范，以及是否暴露新的架构问题。
Founder Product Validation
Fei 从商业与架构角度验证产品行为。
验证确认实现在真实产品 workflow 中是否符合预期。
Decision Proposal Closed
生产行为通过验证，且正本资源反映已解决的决定后，关闭 Decision Proposal。
此时提案不再是正本。
正本是更新后的 canonical resources。
---
Decision Proposal Standard
架构讨论使用 Decision Proposal，替代传统 Issue。
问题影响产品含义、系统边界、语义定义、workflow 行为或长期架构时，使用 Decision Proposal。
每个 Decision Proposal 使用以下结构：
🟡 Observation
当前行为与具体问题。
🔵 Reframed Question
需要解决的架构问题。
🟣 Summary of Solution
founder 决定后填写。
🟢 Proposed Solution
当前提出的方向。
🔴 Decision Needed
需要 Fei 作出的决定。
📝 Founder Notes
founder 的推理、澄清、约束与最终判断。
🟠 Affected Resources
决定影响的 Foundation 文档、Linear 资源、GitHub 范围、生产 workflow 或运营协议。
⚪ Resolution Path
提案如何转化为正本知识与生产行为。
Implementation Checklist
☑ Founder Decision Complete
☐ Resources Updated
☐ GitHub Implemented
☐ Codex Review Complete
☐ Production Verified
☐ Proposal ClosedDecision Proposal 是临时资源。
它用于解决架构不确定性。
问题解决后，持久知识进入正本资源。
随后关闭、归档提案，或把它作为历史语境，不作为现行正本。
---
Codex Review Protocol
每次 GitHub review 只将发现分为以下三类。
1. Implementation Progress
改了什么？
从产品与架构角度解释实现。
不要机械汇总 commits。
2. Specification Drift
实现仍符合 Linear 规范吗？
指出 GitHub 中的行为、架构或产品影响在哪些地方偏离当前正本规范。
3. New Decision Proposal
实现暴露了新的架构问题吗？
指出不能在实现内部静默决定的问题。
新问题若影响产品含义、系统边界、规范语言或未来行为，应形成 Decision Proposal。
Codex review 面向非工程背景的 founder。
重点是架构、行为与产品影响，不是代码语法。
不要生成泛泛的代码摘要。
---
Knowledge Hierarchy
LYNCA 使用固定的知识层级。
Foundation
↓
Project Specifications (Linear Resources)
↓
GitHub Implementation
↓
Production Products
↓
Commercial RealityFoundation 定义公司运营原则。
Project Specifications 定义当前架构正本。
GitHub 实现已接受的规范。
Production Products 呈现实际运行行为。
Commercial Reality 形成新观察，开始下一轮迭代。
知识层级有方向，学习则循环进行。
生产与商业现实可以挑战当前规范。
此时不能通过隐藏的实现漂移处理问题。
应形成新观察、Decision Proposal、founder 决定，并更新正本资源。
---
Design Principles
LYNCA 遵循以下开发原则：
- 先规范，后实现。
- 先定义，后 prompts。
- 先实际应用，后复杂性。
- 人类判断定义架构。
- AI 维护知识。
- 工程实现规范。
- 生产验证决定。
- 知识应随时间积累。
- 过时知识被正本资源吸收后，应退出当前规则。
这些原则让产品判断、知识架构、工程与生产行为保持一致。
---
Long-Term Vision
本流程旨在成为 LYNCA 长期的 AI-native 运营模式。
未来产品应不加修改地继承本协议。
本流程保留 founder 推理、降低组织熵，让 AI 与工程团队通过共享正本规范协作，而不依赖未记录的对话。
LYNCA 应通过更好地记忆，变得更善于构建。
每项产品决策应进入正本知识，或退出当前规则。
每项实现都应能对照规范解释。
每次生产行为偏差都应成为结构化观察。
每个已解决的架构问题都应增强公司的共享记忆。