什么是 AI 原生

「AI原生」不是指在产品中加入一个AI助手按钮，也不是指用AI来辅助某个具体功能。AI原生的含义是：将AI作为产品的主路径，而不是可选的附加功能。在AI原生设计下，AI不是工具——AI是团队的核心工程生产力。开发者的角色从代码编写者转变为方向引导者和关键决策者。

LinaPro在框架设计之初就充分考虑了AI原生开发的需求：

• 一方面构建了规范驱动的AI原生研发工作流，使开发者能够将需求分析、系统设计、代码实现、测试验证等全部开发环节都交给AI来完成；
• 另一方面内置了覆盖研发全生命周期的AI技能体系，让AI在后端开发、前端设计、测试保障、性能审计等每个具体工作场景下都能做出符合框架约束的专业决策。

两者相互配合，共同构成了LinaPro的AI原生设计基础。

AI 原生 vs. AI 辅助

维度	AI 原生	AI 辅助
AI的角色	核心工程生产力，主路径	辅助工具，可选使用
代码来源	AI编写，人类决策	人类编写，AI辅助
文档维护	AI同步维护，与代码强绑定	人类维护，易与代码脱节
架构一致性	规范锚定，AI自动遵循	完全依赖人工审查
测试覆盖	强制E2E测试，变更前提	按需编写，可能缺失
迭代速度	以AI处理速度为瓶颈	受人类编码速度限制

AI 原生开发体系设计

AI 贯穿全开发流程

在LinaPro的AI原生工作流中，AI深度参与了所有开发环节：

• 需求分析阶段： AI读取项目规范（AGENTS.md）、现有OpenSpec文档和源码，深入理解当前架构，主动提出澄清问题，帮助你想清楚边界和影响。

• 系统设计阶段： AI生成数据库表设计、API接口定义、前端页面结构，形成完整的设计文档（design.md）和增量规范（specs/），供你审阅和决策。

• 代码实现阶段： AI按照任务清单（tasks.md）逐条完成实现——后端服务、API路由、数据库DAO层、前端页面组件、权限声明、国际化资源，一气呵成。

• 测试验证阶段： AI编写E2E测试用例，运行测试，确保功能实现与设计规范一致。

• 文档归档阶段： AI将变更中的设计决策、接口规范整理为基线规范，供后续迭代引用。

框架内置 AI 技能体系

AI原生不仅仅意味着一套研发工作流，更意味着框架为AI的每一个工作环节都提供了深度定制的技能（Skill）支撑。LinaPro内置了覆盖研发全生命周期的AI技能体系，让AI在每个具体场景下都能以最高效的方式工作，而无需在每次对话中重复向AI解释项目规范。以下是部分内置技能示例：

类别	技能	核心能力
研发工作流	openspec-*	需求探索、方案提案、设计文档生成
研发工作流	lina-review	代码与规范合规性审查，OpenSpec变更前的质量门禁
研发工作流	lina-feedback	问题追踪、缺陷修复、E2E测试覆盖闭环
前端开发	frontend-design	生产级前端界面设计，避免「千篇一律」的通用AI界面风格
前端开发	frontend-patterns	前端开发模式，状态管理、性能优化、表单处理最佳实践
测试保障	lina-e2e	Playwright E2E测试用例命名、组织与编写规范
测试保障	playwright-cli	浏览器自动化，用于E2E测试执行与调试
质量审计	lina-perf-audit	后端API性能审计，发现N+1查询、缺失索引等性能风险
质量基线	karpathy-guidelines	规避常见LLM编码误区，确保实现精准、不过度设计
版本管理	git-commit-push	分析变更差异，自动生成符合仓库规范的提交信息并推送
版本管理	git-worktree	为并行任务创建隔离的Git工作树，避免互相干扰

这些技能以领域知识的形式内嵌于框架的AI协作规范（.agents/skills/）中，项目内置技能随源码自动加载，AI工具在处理对应场景时会自动激活相关技能。OpenSpec CLI、goframe-v2、find-skills等外部工具或技能仍建议按需安装，以获得完整的规范驱动和后端开发体验。丰富的技能体系带来的直接收益是：AI在每一个具体工作场景下，都能做出符合LinaPro框架约束的决策，而不是依赖模型的通用知识生成不符合项目规范的代码或文档。

渐进式项目规范管理

LinaPro不是把所有规则堆进一个超长提示词，而是采用渐进式项目规范管理策略。AI Agent先读取项目顶层入口，再根据当前任务命中的领域继续读取细则文件。

规范资源	职责
AGENTS.md	顶层规范入口，声明项目定位、强制触发场景、规则加载门禁和规则文件索引
.agents/rules/*.md	按领域拆分的细则，如文档、插件、后端、前端、数据库、测试、开发工具等
.agents/skills/	项目内置技能，让AI在具体场景下使用专门工作流和约束
.agents/prompts/	项目命令和提示词目录，例如OpenSpec相关命令入口
apps/lina-plugins/<plugin-id>/AGENTS.md	插件本地规范入口，只作用于该插件目录内的文件变更

插件本地规范是这套策略的重要部分。开发某个插件时，如果插件目录存在AGENTS.md，AI Agent需要优先读取它；当插件本地规范与项目顶层规范或.agents/rules/*.md存在冲突时，在该插件目录内以插件本地规范为准。未覆盖的部分继续遵守全局规范和命中的规则文件。

这种设计的价值在于：主项目保持统一工程质量基线，插件又可以表达自己的领域约束、目录约定、业务规则和测试要求。随着插件数量增加，AI不需要一次性加载所有插件规则，而是在进入具体插件开发上下文时读取对应本地规范。

为了兼容不同开发者习惯使用的AI Coding工具，LinaPro提供make agents系列命令，把统一来源桥接到各工具自己的约定路径。例如，工具原生读取AGENTS.md时无需额外文件；只读取CLAUDE.md、GEMINI.md或QWEN.md的工具，则可以通过软链使用同一份根规范。技能和提示词也通过同样方式桥接到.claude/skills、.codex/prompts、.cursor/commands等路径。

规范驱动开发

LinaPro的AI原生工作流建立在 规范驱动开发（Specification-Driven Development，SDD） 理念之上。

传统开发模式的问题在于：随着时间推移，文档落后于代码，代码偏离设计，测试覆盖出现空洞，最终形成无人敢动的「祖传代码」。

SDD通过以下机制解决这个问题：

每次变更都有对应的规范锚点

每次功能迭代都会在openspec/changes/目录下产生完整的文档记录，包括设计决策、接口规范和实现细节。这些文档是AI在下一次迭代中的上下文基础。

规范先行，代码跟随

在写任何一行代码之前，AI必须先确定规范（proposal.md和design.md通过审阅），然后才开始实现。这确保了代码和文档在同一个迭代周期内同步产生。

强制E2E测试作为变更前提

每次变更都必须有对应的E2E测试覆盖。测试通过是变更归档的必要条件，而不是可选步骤。这从根本上防止了「测试空洞」的积累。

归档即沉淀

变更归档时，增量规范会合并到openspec/specs/目录中，形成持续生长的基线规范库。AI在后续迭代中会以这些已验证的基线作为约束，保证架构一致性。

为什么不建议人类直接修改代码

这是很多开发者接触LinaPro时会有的疑问：我能不能直接改代码，不通过AI工作流？

可以，但不建议。 原因如下：

文档和代码会立即脱节

LinaPro采用了SDD规范文档（design.md、specs/）描述了系统的当前状态，推荐使用OpenSpec进行管理。如果直接修改代码而不更新规范，下一次AI迭代时，AI会基于过时的规范生成不符合实际情况的设计，导致越来越多的偏差。

AI无法感知「潜规则」

人类在直接修改代码时往往会引入一些隐性约束（这里加了一个特殊判断，那里绕过了某个限制），这些约束存在于开发者脑子里，而不在规范文档里。当AI下次修改同一模块时，很可能会破坏这些隐性约束。

AI可以保证实现与文档的一致性

当AI主导实现时，代码和文档是在同一轮对话中同时产生的，两者必然一致。这是人类工作方式很难达到的效率。

特殊情况

以下场景可以考虑直接修改代码：

• 紧急的线上问题修复（但事后需要补充OpenSpec记录）
• AI无法理解的高度特殊的业务约束
• 配置文件和环境变量的调整

即便在这些场景下，也建议事后通过/lina-feedback技能将修改记录到当前活跃的OpenSpec变更中。

AI 原生框架的价值

LinaPro的AI原生设计带来的核心价值可以归纳为：

• 交付速度：AI可以在几分钟内完成一个完整的CRUD模块，包括后端API、数据库层、前端页面和测试用例，这是人类工程师至少几个小时才能完成的工作量。

• 质量一致性：每次迭代都遵循相同的规范和最佳实践，代码风格、命名规范、错误处理和测试覆盖保持高度一致，不受开发者个人习惯的影响。

• 可持续演进：规范文档随代码同步更新，架构决策有据可查，新成员可以通过阅读openspec/specs/快速理解系统的设计意图。

• 风险可控：每次变更都有E2E测试作为安全网，AI审查机制可以及时发现偏离规范的实现，将问题消灭在合并之前。

• 场景感知：十余项内置AI技能覆盖研发全生命周期，无论是后端API开发、前端界面设计、E2E测试编写，还是性能审计、版本升级、代码提交，AI在每个具体工作场景下都拥有专属领域知识，开发者无需每次重新向AI解释项目规范，极大降低了AI协作的认知摩擦。