本文将以SkillFlow项目开发为例，讲解我个人在使用AI辅助研发上面的经验，涵盖需求分析、代码或架构探索、开发（本地开发|云端开发）、代码review以及CI/CD流程等。

1. Issue

一个项目的开始肯定是从需求出发，我使用linear作为我的项目管理工具。Linear|linear中将一切bug/feature/refactor/feedback等称之为issue，所谓项目管理即issue管理。issue分为internal和external两种。

• internal：项目团队成员自己规划的
• external: 外部客户的诉求

1.1. Internal

根据功能特性、架构模块或版本规划等issues划分多个project。

1. 在规划大粒度特性（project）时，撰写详细项目description，选中后一键转换为issue
   
2. 手工在指定project下创建issues

1.2. External

1. 项目在github开源，用户在github上提交的issues会自动同步到linear中（状态为triage）
2. 我会定期进行人工分类，审视issue的合理性，为合理的issue设置project/label/priority/assignee等，放到backlog中（business计划支持配置规则自动分类）
   

2. Explore

2.1. linear

我日常工作模式是通过FleetingThought这个project进行。将每一个闪念创建为一个issue，通过在评论区@Codex的方式对项目中的细节和疑问点进行提问、探索。这么做的好处是，对话记录作为有效资产可以永久保存，方便回顾。对话可以进行多轮，如果发现项目实现逻辑和实际期望效果不一致，也可以要求Codex立即进行适配修改。
优缺点：

• 回答问题效率较低，需要拉起云上environment，即时分析
• 时效性好，能够基于最新代码进行问答
• 发现问题后，可以立即要求Codex进行修复
  

2.2. deepwiki

deepwiki是个免费的网站，可以对github上的项目进行index并开放给所有游客。每个访问者可以针对特定repo进行提问，LLM会结合项目文档和实际源码做出解答。
优缺点：

• 方便新手学习和入门，界面对话方便
• 回答问题效率较高
• 代码时效性欠缺，每次更新间隔需要7天以上
  

3. Develop

3.1. local develop

我主要使用superpowers这套工作集，让智能体“从需求澄清→设计→计划→实现→审查→收尾”的全过程按规范执行。一个常见的skill工作流：brainstorming→worktrees→writing-plans→subagent-driven/executing-plans→TDD→code review→finish branch

flowchart TD
  A[SessionStart: 平台钩子触发] --> B[注入 using-superpowers 引导上下文]
  B --> C{每次任务前: 技能选择}
  C -->|需求/设计不清晰| D[brainstorming: 产出 spec]
  D --> E[using-git-worktrees: 建隔离工作区/分支]
  E --> F[writing-plans: 产出可执行 plan]
  F --> G{执行能力}
  G -->|有 subagents| H[subagent-driven-development]
  G -->|无 subagents/需并行会话| I[executing-plans]
  H --> J[test-driven-development: 实现中约束]
  I --> J
  J --> K[requesting-code-review: 阶段性审查]
  K --> L{出现 bug/失败?}
  L -->|是| M[systematic-debugging]
  M --> N[verification-before-completion]
  L -->|否| N
  N --> O[finishing-a-development-branch: 合并/PR/保留/丢弃]
  K --> P[receiving-code-review: 接收&实施评审反馈]
  C -->|多域并行问题| Q[dispatching-parallel-agents]
  B --> R[writing-skills: 编写/验证新技能（元工作流）]

3.1.1. skill checklist

3.1.2. Subagent Driven VS Parallel Session

3.1.2.1. Subagent Driven

一个 orchestrator + 多个临时 subagents，每个任务都会生成一个新的子 agent 来执行，像一个 tech lead + 多个 junior dev

Controller (主会话)
        │
        ├─ Subagent <span class="tag">#1</span> → Task 1
        │        └─ Review
        │
        ├─ Subagent <span class="tag">#2</span> → Task 2
        │        └─ Review
        │
        ├─ Subagent <span class="tag">#3</span> → Task 3
        │        └─ Review
        │
        ...

3.1.2.2. Parallel Session

开一个新的 session 批量执行计划，像一个developer连续做任务

Session A
   │
   └── 写 plan
            │
            ▼
Session B
   │
   ├─ 批量执行 task1
   ├─ 批量执行 task2
   ├─ 批量执行 task3
   │
   └─ checkpoint

3.1.2.3. 区别

复杂、有计划的任务：subagent-Driven
简单任务：parallel session

3.1.3. example

3.1.4. 使用systematic-debugging定位git问题

3.1.4.1. 核心逻辑

在完全理解故障根源之前，禁止任何修复尝试

3.1.4.2. 工作原理：科学实验法

该Skill的底层逻辑借鉴了科学实验方法论。它将调试从“修代码”转变为“验证假设”。

1. 因果律优先：它假设任何 Bug 都有一个明确的起点（Root Cause）。目前的错误表现只是“结果”，而“结果”是不值得修复的，必须修复“原因”。
2. 隔离变量：在 Phase 3 中，它要求每次只改变一个变量。如果同时改动多处，你将无法确定是哪个改动起效了，或者是否一个改动掩盖了另一个问题。
3. 证据驱动：它不相信“我觉得”、“应该是”，它只相信日志、堆栈跟踪（Stack Trace）和可复现的测试用例。

3.1.4.3. 执行过程

这个Skill像一个关卡游戏，分为四个关卡，你必须拿到前一阶段的“通行证”才能进入下一阶段：

3.1.4.3.1. 阶段 1：根源调查 (Root Cause Investigation)

• 输入：报错信息、异常表现。
• 动作：
  • 深度阅读：不只看第一行报错，要看完整的堆栈。
  • 复现：找到 100% 触发 Bug 的具体步骤。
  • 插桩 (Instrumentation)：如果系统复杂，在数据流转的每个关口（API -> 数据库）打印日志。
• 目标：指着某一行代码说：“这就是万恶之源”。

3.1.4.3.2. 阶段 2：模式分析 (Pattern Analysis)

• 动作：
  • 找对照组：看看代码库里哪里运行是正常的。
  • 找不同：对比“正常的”和“坏掉的”之间细微的环境、配置或逻辑差异。
• 目标：理解为什么这部分代码违反了预期的工作模式。

3.1.4.3.3. 阶段 3：假设与验证 (Hypothesis and Testing)

• 动作：
  • 写下假设：明确表述“我认为是因为 X 导致了 Y”。
  • 最小化实验：做一个极其微小的改动来验证这个假设。
• 关键点：如果验证失败，撤销改动，回到阶段 1。

3.1.4.3.4. 阶段 4：正式实施 (Implementation)

• 动作：
  • 测试先行：写一个专门针对该 Bug 的失败测试（TDD）。
  • 彻底修复：实施针对根源的修复。
  • 三振出局法：如果你尝试了 3 次修复都失败了，停止修复。这意味着你的架构可能本身就有问题，需要重新审视方案。

3.1.4.4. 效果

3.1.5. 使用工作流对项目进行重构

brainstorming(需求澄清&方案设计) -> 基于TDD开发 -> 收尾阶段验证

1. 使用subagent-driven-development模式开发
2. 创建新的worktree
   
3. 严格遵守TDD模式，每个task按照Red-Green-Refactor流程处理
   
4. commit前进行最后的测试验证
   

3.1.6. openspec

Explore -> Proposal -> Spec -> Design -> Task -> Implement -> Archieve

3.1.7. worktree

git worktree提供了多分支隔离本地文件夹，共享git记录的能力，让本地并发工作成为了可能。常见的使用情况是：

1. 使用多个worktree并行开发多个独立的特性
2. 使用多个worktree并行修复多个bug
3. 让AI在本地开发特性或bug的同时，创建一个新的worktree，用于人工代码review
   不用担心并发开发的合并问题，有了AI，一切都不是问题。

• 要求基于TDD模式开发，通过完善的测试用例保证功能正确性
• 让AI自己完成任务后，自助合并到main分支，自助解决冲突问题，确认测试用例通过
  优点：
• 多任务并行，避免来回切换分支或文件拷贝
• 每个模型看到的上下文独立，不会由于并发文件修改造成的幻觉问题
  

3.2. Cloud Develop

• 上下班途中，逛公园路上，吃饭时，突然想起来一个bug或者idea，按耐不住，想要立即实现
• AI时代，还需要我打开电脑coding？No，一部手机完成全栈开发。

  目前claude code/codex等等主流AI服务厂商都提供了云端开发代码的能力

3.2.1. Delegate work to Codx

1. 评论区@Codex进行提问或任务分配
2. 直接assign任务给Codex
   
   Activity面板可以看到任务完成后的反馈，还可以打开task链接追踪更多细节
   

3.2.2. env & repo

• Environment：Linear会基于问题上下文推荐一个repo。Codex会自动选择一个最符合匹配Linear建议的Environment。如果请求存在歧义的，则使用最常使用的Environment兜底。或者，用户可以显示指定，例如使用 @Codex fix this in shinerio/SkillFlow
• Repo：Task基于codex中environment关联的第一个repo的默认分支运行。（codex中支持给一个github repo创建多个environment）
• 如果没有合适的environment或者repo，Codex会在Linear中回复在重试之前如何解决issue的指令。

3.2.3. mcp

通过mcp工具，本地开发的时候，也可以直接将issue分配给AI完成。
配置命令
codex mcp add linear --url https://mcp.linear.app/mcp
支持功能

🔌  MCP Tools

  • linear
    • Status: enabled
    • Auth: OAuth
    • URL: https://mcp.linear.app/mcp
    • Tools: create_attachment, create_document, create_issue_label, delete_attachment, delete_comment, extract_images, get_attachment, get_document, get_issue,
get_issue_status, get_milestone, get_project, get_team, get_user, list_comments, list_cycles, list_documents, list_issue_labels, list_issue_statuses, list_issues,
list_milestones, list_project_labels, list_projects, list_teams, list_users, save_comment, save_issue, save_milestone, save_project, search_documentation,
update_document
    • Resources: (none)
    • Resource templates: (none)

使用示例：

3.2.4. automation

Business and Enterprise plans可以通过triage rules实现issues自动流转

• 自动将任务分配给Codex
  
• 自动给指定客户打“高优先级”标签
  

4. Review

4.1. Codex

4.1.1. Explicit

通过评论的方式，显示触发Codex review，例如@Codex review it。甚至可以在评论区让Codex重点关注某些方面的内容，如@Codex review代码，重点关注是否存在安全凭据保存不当的问题

4.1.2. automation

在Codex中可以开启自动review，一旦有PR创建，Codex便会自动开启review。

• on PR open
• on every push

4.1.3. Resolve Review

可以使用@codex的方式进行回复，要求codex进行修复，修复后会触发branch update。

4.2. Copilot

Copilot code review is a premium feature available with these plans:

• Copilot Pro
• Copilot Pro+
• Copilot Business
• Copilot Enterprise

5. CI/CD

5.1. CI(Continuous Integration)

• 核心动作： 提交代码 -> 自动拉取 -> 自动编译 -> 自动运行单元测试。
• 目的： 尽早发现代码冲突和逻辑错误。如果测试没通过，构建就会“失败”，开发者必须立即修复。

5.1.1. settings

定义CI流水线

on:
  pull_request:
    branches:
      - main
    types:
      - opened                  # 新建PR时跑
      - synchronize             # PR分支有新提交时跑
      - reopened                # 重新打开PR时跑
      - ready_for_review        # 从draft转正式时跑

设置CI门禁：settings -> rules -> rulesets

• Require a pull request before mergingRequire all commits be made to a non-target branch and submitted via a pull request before they can be merged.
• Block force pushes
• Require status checks to pass -> verify-main
  不允许push
  
  门禁未通过，不允许合入
  
  门禁通过后，方可合入

5.2. CD(Continuous Delivery）

5.2.1. settings

commit with tag v*

on:
  push:
    tags: ['v*']

携带tag v*的commit被push后会自动触发release流水线，发布macos/windows版本客户端。

release版本发布，用户收到新版本更新消息，完成一个版本迭代

6. About SkillFlow

skillflow的项目开发动机：

• 【资产内化】 解决“收藏即遗忘”的困境。将散落于博客、视频中的碎片化skill转化为可管理、可迭代的个人资产，明确技能效用，建立淘汰与更新机制。
• 【透明掌控】 拒绝技能管理的“黑盒”状态。对海量技能按场景（编程/写作/绘图）分类归档，确保开发者对智能体能力边界拥有完全知情权与控制权。
• 【多端同步】 打破模型孤岛。针对 Claude Code、Codex、Gemini 等多智能体在特性、额度及使用场景上的差异，实现技能配置在不同智能体间的无缝同步与复用。
• 【自动迭代】 摒弃繁琐的人工维护。建立技能自动更新机制，解决来源分散导致的版本滞后问题，确保技能库时刻处于最新状态。
• 【提示词工程】 实现提示词（Prompt）的版本化管理。杜绝重复编写造成的实际效果参差不齐，推动提示词的持续优化与标准化迭代。
• 【环境一致性】 构建跨设备云同步体系。屏蔽 macOS/Windows 多设备异构环境差异，确保在任何办公场景和办公设备开发环境与技能配置的高度一致。
• 【实战驱动】 拒绝低效的重复练习（如坦克大战、个人博客）。以解决真实生产力痛点为导向，在掌握 AI 技术的同时，打造真正赋能开发的实用工具，实现“学以致用”的闭环。

7. Afterword

Stop collecting skills, stop reading blogs, just start practicing.