小南的博客 https://tangly1024.com/ 一个博客 Sun, 10 May 2026 02:47:38 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, 小南 <![CDATA[07 Vibe Coding ]]> https://tangly1024.com/article/VibeCoding-007 https://tangly1024.com/article/VibeCoding-007 Fri, 10 Apr 2026 00:00:00 GMT
😀

SDD 三大框架对比

1 三大框架核心信息

框架名称
定位标签
背景与适用场景
核心流程/特点
特性
OpenSpec
最轻量
Fission-AI (YC) 出品 三步工作流 适合 Brownfield（遗留项目）+ 轻量变更
聚焦「为什么做这个变更」（变更上下文）
✅ /verify 三维验证 ✅ Delta Spec 增量更新 ✅ 24+ AI 工具 零锁定
spec-kit
最完整
GitHub 官方出品 四步流程 适合 Greenfield（全新项目）大型项目
聚焦「该构建什么」（规格说明）
✅ Constitution 深度约束 ✅ 项目级规则强制执行 ✅ 完整需求→代码全流程
Superpowers
最自动
obra·Skills 框架 适合高质量交付场景
聚焦「代码写对了吗」（质量保证）
✅ 自动 TDD 纪律性执行 ✅ 行为驱动开发内置 ✅ Skills 自动化流程

2 三框架核心差异（互补不互斥）

  1. OpenSpec：负责「为什么做这个变更」——管理变更上下文，适配遗留项目与轻量迭代
  1. spec-kit：负责「该构建什么」——管理规格说明，为大型新项目提供完整流程与约束
  1. Superpowers：负责「代码写对了吗」——管理质量保证，通过自动化流程保障交付质量
notion image
notion image

OpenSpec

OpenSpec 项目架构 & 工作流

核心定位：类 Git 逻辑，管理需求规格变更

1 项目架构（src/ 目录）

模块
核心内容
cli/
Commander.js 命令行入口
commands/
命令实现层，封装子命令逻辑
core/（重点）
init.ts（29KB 核心文件）、archive.ts（归档+Delta 合并）、specs-apply.ts（Delta 合并算法）、Zod 验证、24 个 AI 工具适配器
prompts/
AI 交互 Prompt 模板
schemas/
内置工作流 Schema 定义
核心文件速记：init 控核心流程、archive 管归档、specs-apply 是 Delta 算法核心

2 核心工作流（标准四步）

步骤
操作
核心作用
1
openspec init
初始化项目，检测并配置 AI 工具
2
/opsx:propose
AI 生成提案（Why 变更原因+规格变更+任务清单）
3
/opsx:apply
按任务清单，落地规格变更至代码
4
openspec archive
Delta 合并入主规格，归档 Why/What/How 变更记录

3 两种工作流模式

模式
流程
特点
Core（默认）
propose → apply → archive
3 步完成，简洁高效，适配常规迭代
Expanded
new → continue → apply → verify → archive
5 步流程，支持精细控制，适配复杂变更

4 Delta 规格系统（类 Git diff）

变更类型
标识
核心说明
示例
新增
ADDED
新增需求条目（含 Given/When/Then 场景）
导出 PDF 功能
修改
MODIFIED
调整已有需求
登录超时 30min→15min
删除
REMOVED
废弃需求（历史完整归档）
旧版 API 过渡至 v2 后不再维护

OpenSpec 安装 & 目录拆解

核心定位：三步安装，快速搭建 AI 协作基础设施

1 安装三步流程

步骤
操作
核心说明
1
npm install -g openspec
全局安装，要求 Node.js ≥ 20.19
2
openspec init
交互式生成项目目录结构
3
config profile
配置单/多命令，适配不同工作流

2 目录结构拆解（openspec/）

目录/文件
核心作用
config.yaml
项目配置，主动注入每次请求
specs/
系统当前行为的完整描述（源真相）
changes/
变更提案区，每个功能一个独立文件夹
🔗 Git 类比
  • specs/ ≈ main 分支 — 「当前系统长什么样」
  • changes/ ≈ feature 分支 — 每个功能独立开发
  • archive ≈ merge — 归档时合并变更到主 Spec

3 命令 Profile 类型

类型
包含命令
特点
core profile
propose / apply / archive
仅 3 个核心命令，简洁高效
custom profile
propose/apply / archive/verify / onboard/sync 等
共 11 个命令，支持更精细的流程控制
切换命令示例：

4 跨工具语法差异

工具
命令语法
说明
Claude Code
/opsx:propose
冒号分隔
Cursor / Windsurf
/opsx-propose
连字符分隔
所有工具
功能完全相同
仅语法形式不同，逻辑一致

config.yaml · 项目的「AI 宪法」

核心定位：替代传统 project.md，以 主动注入 替代 被动读取，保障 AI 协作确定性

1 为什么用 config.yaml？

对比项
旧方案（project.md）
新方案（config.yaml）
读取机制
被动读取，AI 可能读不到
主动注入，100% 生效，无遗漏
稳定性
不确定（读/不读全看 AI）
100% 稳定，强制注入每个请求
定位
文档参考
AI 协作核心配置（项目的“宪法”）

2 三层结构（从基础到核心）

层级
作用
特点
schema
定义工作流类型
基础配置，一般不改
context
全局上下文，核心层
极度精炼，主动注入每个请求
rules
格式规则约束
按 artifact 类型分层（proposal/specs/design/tasks 各有标准）

3 context 三铁律（核心准则）

原则
核心要求
目的
✅ 极度精炼
只写 AI 不知道的项目特殊约定；通用最佳实践不用写
减少 token 消耗，避免冗余
✅ 活文档
AI 忽略了就加，膨胀了就剪
始终保持精炼、有效
✅ 超 10 行审视
context 每字都是 token 成本
控制长度，优化性能

4 核心结论

主动注入 > 被动读取 context 每一字节都是 token 成本 → 精炼是优化性能的第一步

CLAUDE.md 分阶段交互

核心目标：通过分阶段控制，防止 AI 「错上加错」，大幅降低修复成本

1 核心规则

在 CLAUDE.md 中写明交互规则：
每完成一个 Phase → 暂停总结 → 等待用户确认 → 再继续下一个阶段

2 两种交互模式对比

对比项
无分阶段规则（AI 默认行为）
有分阶段规则（CLAUDE.md 控制）
执行逻辑
AI 一口气写完所有 Phase，追求快速交付
每完成一个 Phase 必须暂停，先总结变更，等待确认再继续
偏差处理
Phase 1 出现理解偏差后，后续阶段在错误上继续堆叠
Phase 1 完成即可发现偏差，仅需修正约 50 行代码，损失最小
问题暴露时机
写 500-1000 行代码后，才发现方向根本错误
偏差早期暴露，可立即调整方向，后续阶段在正确基础上推进
修复成本
极高，几乎等于全部重写
极低，仅需修正少量代码，避免大规模返工
核心效果
错上加错，越走越偏
小步快跑，精准迭代，全程可控

3 关键结论

  • 分阶段控制是 AI 协作的“刹车”，能把错误扼杀在早期阶段
  • 修复成本差异巨大：50 行 vs 1000 行，本质是「小修小改」和「推倒重来」的区别
  • CLAUDE.md 规则的核心，就是强制 AI 进入「暂停-确认-继续」的循环，避免一次性写死

OpenSpec 三步核心工作流 + 四件制品

核心目标：用「先设计、后编码」的方式，把返工时间压到最低

1 完整工作流（含可选步骤）

  • 关键节点：propose 阶段生成全部四件制品，是整个流程的核心输入

2 四件制品详解（核心交付物）

制品
定位
核心内容
proposal.md
为什么做
意图：变更要解决的问题<br>范围：影响的模块<br>方法：大致实现思路<br>out-of-scope：明确不做什么，防止 AI 越界
specs/
做什么
Delta Spec 格式（只写变化部分）：<br>• ADDED 新增需求<br>• MODIFIED 修改已有需求<br>• REMOVED 删除需求<br>（不重写整个文件，是 OpenSpec 高效的关键）
design.md
怎么做
技术方案选型<br>架构决策及理由<br>数据流描述<br>涉及的文件清单
tasks.md
执行清单
带 checkbox 的分阶段任务<br>按 Phase 分组，每个 Phase 有验证步骤<br>AI apply 时逐个标记 [x]<br>checkpoint 防止 AI 跑偏

3 效率对比：直接写代码 vs OpenSpec 流程

方式
时间投入
结果
直接写代码
2h 编码 + 1h 返工 = 3h ❌
返工成本高，方向错误代价极大
OpenSpec 流程
propose 5min + review 10min + apply 1.5h + verify 5min ≈ 2h ✅
省的不是编码时间，是返工时间

4 核心认知

  • propose 不是写代码，而是交出设计方案给你审查
  • 审查几十行的设计，比审查几百行的代码容易 10 倍
  • 上游花 10 分钟打磨 proposal，能省下下游 2 小时返工
  • 工程实践：先结构化需求 + 总结架构，再进行 propose

out-of-scope 关键点 & Review 不可跳过

核心原则：明确“不做什么” + 严格执行评审，杜绝 AI 越界与返工

1 AI 的「善意」陷阱

场景
风险表现
核心逻辑
需求不完整
只要求导航栏，AI 顺带引入动画库、搜索功能
AI 会基于“善意”补充未明确需求
后果
功能溢出，偏离预期
未声明“不做什么”，AI 无法判断边界
关键认知
告诉 AI「不做什么」，和告诉它「做什么」同等重要
双向定义才能精准控制范围

2 out-of-scope 实操

操作
具体示例
效果
在 proposal.md 中明确写出「不做」清单
✅ 不做动画效果<br>✅ 不做搜索功能<br>✅ 不接入后端 API
AI 严格遵守，绝不越界，100% 可控

3 Review 不可跳过

环节
内容
成本对比
时机
propose 阶段之后
-
审查对象
「设计方案」（几十行），而非直接看代码（几百行）
设计评审成本远低于代码返工
耗时
仅需 5-10 分钟
-
价值
发现问题 → 改设计方案，成本极低
避免后续生成 1000 行错误代码的大规模返工
核心结论
越早发现问题，修改代价越小
本质是“止损”，而非节省时间

4 反模式 #2：跳过提案打磨，直接 apply

反模式
形象类比
后果
不做 propose 和 review，直接执行代码生成
不看建筑图纸直接开工
最常见的反模式，代价最高，必然返工

5 完整 OpenSpec 闭环

完整 OpenSpec = in-scope 清单 + out-of-scope 清单 + review 通过 → AI 精准执行，绝不越界

/opsx:verify 三维验证 · 一页速记清单

核心定位：事后验证（代码写完后），通过 3C 模型查漏补缺，确保交付质量，而非“唯一防线”

1 三维验证框架（3C Model）

维度
核心问题
检查要点
Completeness（完整性）
所有任务完成了吗？需求都有对应代码吗？
✅ 全任务 Check 状态<br>✅ 全需求覆盖代码实现
Correctness（正确性）
实现匹配规格意图吗？边界条件处理了吗？
✅ 实现与 Spec 一致<br>✅ 边缘场景已处理
Coherence（一致性）
design.md 方案在代码中体现了吗？命名一致吗？
✅ 代码落地设计方案<br>✅ 命名/结构无冲突

2 真实输出样例

3 输出三级判定

等级
定义
处理策略
CRITICAL（必须修复）
阻断归档的致命问题
必须修复，否则无法归档
WARNING（建议修复）
不阻断归档的潜在风险
建议修复，不强制阻断
SUGGESTION（锦上添花）
优化建议，非硬性要求
按需采纳，提升质量

4 关键认知与边界

🚨 啊哈时刻
  • AI 跑完 apply 可能自认“搞定”，但 /opsx:verify 能快速暴露 WARNING
  • 验证的核心价值：在“以为做完”的瞬间，用规范判定实际未完成
🆚 与 /analyze 的区别
命令
阶段
定位
关系
/opsx:verify
事后验证
代码写完后，校验交付物
两者互补，不替代
/opsx:analyze
事前检查
文档/提案阶段，预排风险
ㅤ

5 核心原则

  1. verify 不阻止归档：即使存在 WARNING，用户仍可选择归档，拥有最终决定权
  1. 第一道防线：verify 是质量把关的首要环节，但不是唯一防线
  1. 省返工：通过早期校验，把问题扼杀在归档前，降低后期维护成本

Delta Spec——只写变化，不重写整个需求

1 全量 Spec vs Delta Spec 对比

方式
操作
缺点
❌ 全量 Spec
每次改需求都要重读整个 spec 文件、重写全部章节内容
AI 需处理大量 token，容易「丢东西」
✅ Delta Spec
每个 change 只描述自己的变化，spec 文件很小
AI 精准处理，不容易「丢东西」

2 Delta Spec 三种变更类型

  • ADDED：新增需求
  • MODIFIED：修改已有需求
  • REMOVED：删除需求
实操场景示例
以 add-projects-section 变更为例：
  • ADDED: 新增 Projects 展示区域
  • MODIFIED: Hero CTA 按钮锚点改为跳转 → #projects

3 归档行为

  • ADDED：追加到主 spec
  • MODIFIED：替换对应部分
  • REMOVED：从主 spec 删除

4 为什么高效

  • 每个 change spec 文件很小 → AI token 消耗少
  • 不容易「丢东西」
  • 精准聚焦当前变化

5 MODIFIED vs 新建 spec 决策规则

  • 扩展已有模块 → 使用 MODIFIED
  • 全新业务域（首次） → ADDED 新文件
  • 判断依据：主 spec 里有没有对应内容？

6 核心结论

每个 Delta Spec 文件只有变化部分 → AI 精准聚焦 → 不丢需求，不错改

项目：开发一个可部署的个人品牌站

OpenSpec SDD 驱动开发工作流
🗒️
模版
config.yaml
CLAUDE.md

初始项目环境搭建+ OpenSpec 初始化

Step 1 全局配置 OpenSpec

Step 2 创建前端项目脚手架

Step 3 配置 OpenSpec 的 宪法

Step 4 创建项目宪法（CLAUDE.md）

Change 1 ：开发品牌站的 Hero-Section

Step 5 使用 Open Spec 的探索模式

/opsx：explore

Step 6 确定 Change 1的 提案

Step 7 开始分阶段执行Change 1的 代码生成

Step 8 针对 Change 1的apply 结果进行三维校验

Step 9 针对 Change 1 完成Spec归档

Change 2 ：开发品牌站的 navigation

Step 10 确定 Change 2的 提案

Step 11 确定 Change 2的 提案并开始构建代码！

加快节奏

Step 12 针对 Change 2的apply 结果进行三维校验

Step 13 针对 Change 2 完成Spec归档

Change 3 ：OpenSpec Delta Spec 的功能标记

Step 14 Change 3 提案 并 测试 修改的功能标记

Step 15 一次性完成 Change 3 的所有变更流程

Step 16 针对 Change 3 完成Spec归档

Change 4 ： 配置 About Section + SEO优化 + 部署上线

Step 17 Change 4 继续丰富个人品牌站

Step 18 Change 4 添加网站的 SEO优化策略

Step 19 单次执行多步的提案文件

Step 20 个人品牌站部署上线

notion image

📎 参考文章

  • 一些引用
  • 引用文章
 
💡
欢迎您在底部评论区留言，一起交流~
 
 
]]> <![CDATA[06 Vibe Coding]]> https://tangly1024.com/article/VibeCoding-006 https://tangly1024.com/article/VibeCoding-006 Fri, 10 Apr 2026 00:00:00 GMT
😀

产品研发方法论

notion image
notion image

Claude Code Agent Teams协作原理

notion image
notion image
notion image
notion image
notion image

项目：文档审核Agent

notion image
notion image
notion image
notion image

1 Agent Teams 市场调研&竞品分析拆解

Step 1 配置项目运行环境

https://code.claude.com/docs/zh-CN/agent-teams

Step 2 Agent Teams + LangChian MCP 的接入能力校准

Step 3 Agent Teams 启动市场调研

Step 4 Agent Teams 启动竞品分析

Step 5 核心业务建模

2 系统业务建模 & 核心交互链设计

Step 6 核心交互链路设计

Step 7 前端的原型需求 + 前后端的职责边界

Step 8 后端的系统架构设计

Step 10 核心的数据模型设计

Step 11 后端 FastAPI 接口设计规范文档生成

Step 12 PRD需求文档生成

3 前后端接口联调 & 自动化测试交付

Step 13 根据 PRD 在 Figma 开发系统前端的源码！（Figma 中）

上传文件：api_spec-v1.0.md、frontend_design_spec-v1.0.md、frontend_arch-spec-v1.0.md

Step 14 创建真实的项目规范

这里需要初始化项目，创建项目目录，创建项目规范等，这步在step 2 中创建了claude.md，已经做了，这里就不需要了。

Step 15 后端MVP实现

Step 16 前端项目的本地运行配置

Step 17 前后端接口联调

小结

notion image

📎 参考文章

  • 一些引用
  • 引用文章
 
💡
欢迎您在底部评论区留言，一起交流~
 
 
]]> <![CDATA[05 Vibe Coding]]> https://tangly1024.com/article/VibeCoding-005 https://tangly1024.com/article/VibeCoding-005 Fri, 10 Apr 2026 00:00:00 GMT
😀

1 多模态RAG问答系统技术架构拆解

1 设计系统架构

notion image
notion image
notion image

2 技术调研

DeepResearch（ChatGPT + Gemini + DeepSeek ）

3 确定后端知识图谱构建框架

Google ： https://github.com/google/langextract
LangExtract 是一个 Python 库，利用大型语言模型（LLM）根据用户自定义指令从非结构化文本中提取结构化信息。它处理临床笔记或报告等材料，识别并组织关键细节，同时确保提取的数据与原始文本相符。

4 对 LangExtract 进行详细的源码拆解

拆解可以参考之前 OpenClaw 源码拆解思路
notion image

5 生成 LangExtract 源码解析后的规范文档

2 多模态RAG问答系统-文档解析模块开发

6 寻找解析模块 并分析MinerU官方文档

开源项目部署+ 源码拆解思路https://github.com/opendatalab/MinerU （可以参考 OpenClaw 源码拆解思路）

7 MinerU 解析模块的规范文档生成

8 基于生成的规范文档直接建立MVP测试代码流程

9 更新 MinerU MVP 后的Spec 文档规范

3 多模态RAG问答系统-知识图谱提取模块MVP构建测试

10 掌握 Claude.md 的使用

notion image

11 开始尝试将 MinerU 解析后的文本 传入到 LangExtract中(MVP)

开始构建 LangExtract的 MVP 流程

12 更新 LangExtract MVP 后的Spec 文档规范

4 多模态RAG问答系统-GraphRAG索引完整Pipeline-MVP搭建

13 MinerU 和 LangExtract 对接Plan

MinerU 和 LangExtract 对接，实现完成的Pipeline:
读取 本地文档 - MinerU 解析 - LangExtract 信息抽 - 知识图谱结构化数据
 
注意：这里建议大家先做 Plan 生成计划并审核（plan 模式）

14 完成GraphRAG 索引阶段的规范文档生成

15 前端可视化功能测试

neo4j 、知识图谱的前端展示 、 信息抽取的后台管理

5 多模态RAG问答系统-后端系统架构设计及规范文档生成

后期需要完成的工作：
1. 基于 Bridge Pipeline 基础，再次扩展，将Bridge Pipeline 的输出 作为 LangChain Agent 的输入，构建完整的 Agentic-RAG 流程 2. 基于完整的后端 Pipeline（MinerU + LangExtract + LangChain Agent），设计 PRD需求文档，生成 前端UI 原型的完整 Prompt 3. 基于 PRD + Prmpt，在 Figma 设计产品原型 + 多步迭代调试 4. 生成后端服务完整代码 + 前端完整系统代码 5. 前后端真实 API 接口对接 & 联调 6. 本地运行并上线

16 需要 LangChain Agent 构建 Agentic-RAG问答流程

  1. 接入 langChain 的 MCP server 获取最新的版本规范
https://docs.langchain.com/use-these-docs#connect-with-claude-code

17 构建 MinerU + LangExtract + LangChain QA的 Agentic-RAG 的MVP 测试链路

 

18 输出完整的后端 Agentic-RAG Pipeline的规范文档

notion image

19 通过 Plan 模式，基于已经生成的规范文档设计后端的架构和API接口

notion image
Plan Mode

6 多模态RAG问答系统-基于PRD使用Figma生成前端产品原型

20 基于后端的系统架构规范，规划前端的产品原型（整体的）

Plan Mode

21 基于前后端规范文档，生成 PRD需求文档

22 使用 Figma 基于PRD 文档设计前端产品原型

推荐的前端产品设计工具：https://www.google.com/search?q=figma
https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server
https://docs.pencil.dev/getting-started/ai-integration#mcp-model-context-protocol
把生成的prd给到figma，在figma中生成原型

7 多模态RAG问答系统-前后端并行开发&集成测试

23 构建项目之前，先建立项目规范（CLAUDE.md）

24 基于规范文档，生成后端的系统代码

25 多步迭代调试前端(figma中)

figma生成可能是英文，改成中文
更改logo，网站标题 ……

26 下载修改好的前端源码，并完成本地的部署启动

27 编写 前端的 CLAUDE.md

28 编写 后端的 CLAUDE.md

8 前后端接口的联调

29 前后端接口对接及接口集成测试

notion image
notion image

9 工程化开发经验

notion image

📎 参考文章

  • 一些引用
  • 引用文章
 
💡
欢迎您在底部评论区留言，一起交流~
 
 
]]> <![CDATA[04 Vibe Coding]]> https://tangly1024.com/article/VibeCoding-004 https://tangly1024.com/article/VibeCoding-004 Fri, 10 Apr 2026 00:00:00 GMT
😀

Claude Code

  • 工具系统设计：Claude Code 内置了 Read、Write、Edit、Bash、Grep、Glob 等精心设计的原子
  • 工具，每个工具都有明确的边界和安全约束。这套工具体系的设计思路，可以直接迁移到自定义Agent 项目中。
  • 记忆管理架构：CLAUDE.md（项目级记忆）+ Auto Memory（自动记忆）的双层架构，解决了Agent 的"长期记忆"难题，成熟度超过大多数开源 Agent 框架的记忆方案。
  • 上下文工程：Claude Code 的 /compact 命令背后是一套精密的上下文压缩与管理策略，它解决的是所有 Agent 都面临的核心挑战——如何在有限的 Context Window 里塞下无限的世界知识。
  • 人机协作模式 (Human-in-the-Loop)：Claude Code 的权限确认机制、Checkpoint 回滚机制、Plan Mode 等设计，展示了 Agent 与人类如何高效且安全地协作。
  • 扩展生态：Skills / MCP / Plugin 三套扩展体系，分别解决了"业务逻辑封装"、"外部能力连接"和"社区生态接入"三个不同层次的问题。
Claude Code 的架构可以拆分为六大核心系统，各自承担不同的职责，共同构成一个完整的 Agent 工作闭环：
notion image

1 内置工具系统：Agent 的执行引擎

内置工具是 Claude Code 与外部世界交互的唯一通道——模型本身不能直接操作文件系统或执行命令，所有操作都必须通过工具调用 (Tool Use) 完成。Claude Code 内置了以下核心工具：
notion image

2 多级记忆系统：跨会话的知识沉淀

notion image

3 项目管理系统：Checkpoint 回滚与安全保障

让 AI Agent 自动修改代码，最大的担忧是：改坏了怎么办？ Claude Code 的项目管理系统通过Checkpoint（检查点） 机制解决了这个问题。
工作原理：Claude Code 在每次产生文件变更时，自动创建一个 Checkpoint，记录变更前的文件快照。如果对某次修改不满意，可以随时回滚到任意历史检查点——类似 Git 的 commit，但粒度更细，精确到每一轮对话中的每一次文件操作。
实际效果示例：Claude Code 重构了 3 个文件后，你发现新的实现方案不合适。通过 /rewind 命令选择回滚点，一键恢复到重构前的代码状态——所有被修改的文件恢复原貌，新创建的文件被删除，干净利落。

4 斜杠命令系统：Agent 的控制面板

斜杠命令是与 Claude Code 交互的快捷控制方式——在对话输入框中键入 / 即可调出命令菜单。
截至 2026 年 3 月，Claude Code 内置了 59 个斜杠命令（含别名），覆盖了从会话管理、模型切换到扩展配置的方方面面。

1 会话管理

命令
功能
别名
/clear
清空当前对话历史，释放上下文
/reset、/new
/compact [指示]
压缩对话历史，可指定保留重点
—
/resume [会话]
按 ID / 名称恢复指定历史会话
/continue
/fork [名称]
从当前对话创建分支副本
—
/rename [名称]
重命名当前会话
—
/export [文件名]
导出对话为纯文本文件
—
/exit
退出 CLI
/quit

2 模型与模式

命令
功能
别名
/model [模型名]
切换 AI 模型（左右箭头调整 Effort Level）
—
/plan
进入 Plan Mode（先规划后执行）
—
/fast [on\|off]
切换快速输出模式
—
/output-style [风格]
切换输出风格（Default / Explanatory / Learning）
—
/vim
切换 Vim / Normal 编辑模式
—

3 项目与上下文

命令
功能
别名
/init
初始化项目，生成 CLAUDE.md
—
/add-dir <路径>
向当前会话添加额外的工作目录
—
/context
可视化当前上下文使用情况（彩色网格）
—
/diff
打开交互式 Diff 查看器，查看未提交的变更
—
/rewind
回滚对话和 / 或代码到历史检查点
/checkpoint
/pr-comments [PR]
获取 GitHub PR 的评论
—
/review
对 Pull Request 进行代码审查
—
/security-review
分析当前分支的变更是否存在安全漏洞
—
/copy
复制上一条 AI 回复到剪贴板
—

4 配置与状态

命令
功能
别名
/config
打开配置界面
/settings
/permissions
查看 / 修改工具权限
/allowed-tools
/memory
编辑 CLAUDE.md 记忆文件，管理自动记忆
—
/doctor
诊断安装和配置状态
—
/status
显示版本、模型、账户和连接状态
—
/cost
显示当前会话 Token 用量和费用（API 用户）
—
/stats
可视化每日用量、会话历史和使用模式
—
/usage
显示订阅套餐限额和速率限制状态
—
/theme
更换颜色主题（含深色 / 浅色 / 色盲友好版本）
—
/statusline
配置终端状态栏信息
—
/keybindings
打开快捷键配置文件
—
/terminal-setup
配置终端快捷键（如 Shift+Enter）
—

5 扩展与 Agent

命令
功能
别名
/mcp
管理 MCP Server 连接和 OAuth 认证
—
/skills
列出可用的 Skills
—
/plugin
管理 Plugin 插件
—
/agents
管理自定义 Agent 配置
—
/tasks
列出和管理后台任务
—
/hooks
管理 Hook 事件配置
—

6 账户与平台

命令
功能
别名
/login
登录 Anthropic 账户
—
/logout
登出 Anthropic 账户
—
/upgrade
打开套餐升级页面
—
/extra-usage
配置超额使用（限额触达后继续工作）
—
/privacy-settings
查看 / 修改隐私设置（Pro/Max 用户）
—
/desktop
将当前会话转移到桌面应用
/app
/mobile
显示移动端 App 下载二维码
/ios、/android
/chrome
配置 Chrome 集成设置
—
/ide
管理 IDE 集成状态
—
/remote-control
允许从 claude.ai 远程控制此会话
/rc
/remote-env
配置远程环境默认值
—
/install-github-app
安装 Claude GitHub Actions App
—
/install-slack-app
安装 Claude Slack App
—

7 信息与反馈

命令
功能
别名
/help
显示帮助信息和可用命令
—
/feedback [报告]
提交使用反馈或 Bug 报告
/bug
/release-notes
查看版本更新日志
—
/insights
生成使用分析报告（项目领域、交互模式、摩擦点）
—
/stickers
订购 Claude Code 贴纸
—
/passes
分享免费试用周（符合条件的账户可见）
—

8 内置 Skills（以斜杠命令形式触发）

命令
功能
/simplify
审查近期变更代码的复用性、质量和效率，自动修复发现的问题
/batch <指令>
将大规模代码变更分解为 5-30 个独立子任务，并行派发给 Agent 在隔离的 Git Worktree 中执行
/debug [描述]
读取会话调试日志，诊断 Claude Code 自身的运行问题

5 扩展能力系统：MCP、Skills 与 Plugin

notion image

6 多 Agent 协作系统

传统的 AI 编程助手是"单线程"的——一次只能处理一个任务。Claude Code 的多 Agent 系统打破了这一限制，引入了 Sub-Agent 委托和 Agent Team 两种协作模式。
  1. Sub-Agent（子智能体委托）
Claude Code 在处理复杂任务时，可以自主派生出一个或多个 Sub-Agent，将子任务委托给它们并并行处理。每个 Sub-Agent 拥有独立的上下文和工具权限，完成后将结果汇报给主 Agent。
  1. Agent Team（智能体团队）
这是更高级的多 Agent 编排模式（实验性功能），允许定义多个具有不同专长的 Agent 组成团队，协同完成复杂项目。

Claude code 配置

ccstatusline-zh
huangguang1999 • Updated Apr 20, 2026

使用&开发

  1. 完整十八开发阶段研发流水线
notion image
  1. Claude Code 前后端设计规范
notion image
  1. Claude Code 可观测闭环
notion image
  1. Claude Code 对话模式技巧
notion image
  1. Claude Code 工具体系
notion image
  1. Claude Code 权限模式关系图
notion image
  1. Claude Code 工具权限关系
notion image
  1. Claude Code Bash 虚拟环境选择策略
notion image
  1. Claude Code Memory
notion image
  1. .claude/rules/*.md 项目规则详解
notion image
  1. Claude Code 实战经验分享
notion image
 
 
 

📎 参考文章

  • 一些引用
  • 引用文章
 
💡
欢迎您在底部评论区留言，一起交流~
 
]]> <![CDATA[02 Vibe Coding]]> https://tangly1024.com/article/VibeCoding-002 https://tangly1024.com/article/VibeCoding-002 Fri, 10 Apr 2026 00:00:00 GMT
😀

1 从零开发AI对话应用

01 Plan模式下提出规划
这里会列出一个实现流程，不要直接在IDE中开始执行，他会直接把所有步骤执行，之后修改和优化不方便。所以这里要把它生成的流程拆分
02 拆分phase
03 调整phase
04 执行phase1
05 执行 phase2
06 模型接入前测试
从官网找到ds相关的api文档信息，添加到提示词中
在进行前后端对接时，先从官方文档找到相关API的文档，将示例代码添加到提示词中，先进行接口的测试，把返回的接口参数再作为提示，进行后端开发和前端对接
07 基于测试好的接口规范，与前端进行对接
07 最后一步
08 最后细节优化
09 代码推送

2 智能数据分析代理

1 Planning 需求梳理

需求：智能数据分析系统
  1. 接入大模型
  1. 能够操作数据库，基于用户的自然语言查询数据库返回最终的结果
  1. 需要在前端实时的渲染查询出来的可视化图表
notion image
这里使用gpt5.2进行深度研究
根据模型提示补充研究信息

2 确定系统架构

notion image
notion image

3 Cursor plan

生成 代码结构及系统架构、功能规划
不要直接按生成的TODO list执行，先拆分phase
拆分phase
Phase 1:前后端基础框架搭建与运行测试
Phase 2:前端UI研发
Phase 3:后端接口研发
Phase 4:前后端联调

4 linear.app任务管理，cursor接入mcp,创建rule

集成，连接，授权 任务状态管理，cursor settings，Tools&MCP，new MCP server
添加好 MCP 工具后，可以在Agent 模型下进行测试
notion image
为了构建AI驱动的自动任务管理需要使用 Rules 搭配 MCP 来做自然语言的触发
自定义创建 Rule
不要自己写，让ai写，先给官方链接问什么是rule，获得rule上下文，然后让ai创建rule
同步之前plan做的TODO list 到linear

5 分步执行任务

Phase 1

Phase 2

Phase 3

接入langchain mcp
在开始后端开发时，因为要使用langchain，所以先添加了langchain mcp，同时通过mcp问智能体可以接入qwen3的组件，以及可以实现nl2sql的组件，获取上下文信息，并更新规范，确保接口参数正确
https://docs.langchain.com/use-these-docs
notion image

Phase 4

打开网站测试：请查询各个产品类别的销售趋势，并按照销售额排序

整体流程

notion image

📎 参考文章

  • 一些引用
  • 引用文章
 
💡
欢迎您在底部评论区留言，一起交流~
 
]]> <![CDATA[01 Vibe Coding]]> https://tangly1024.com/article/VibeCoding-001 https://tangly1024.com/article/VibeCoding-001 Fri, 10 Apr 2026 00:00:00 GMT
😀

01 什么是 Vibe Coding

🔥 核心定义

Vibe Coding 是用自然语言描述需求，AI 自动生成代码的开发模式，核心是Describe→Generate→Validate→Refine的非线性迭代循环，而非一次性线性产出。

✅ 看起来简单（优势）

  1. 零语法门槛：无需精通语法，自然语言即可提需求
  1. 快速出活：高效生成简单页面、小工具、原型
  1. 体验友好：少受语法阻碍，快速看到开发成果

❌ 实际很难（挑战）

  1. 精准度难题：自然语言有歧义，Prompt 设计是核心技能
  1. 输出不稳定：AI 代码质量波动，需反复验证、调整
  1. 工程硬门槛：要理解、调试、修正代码，复杂系统依赖扎实工程能力

🎯 核心定位

  1. 新手友好：模糊技术细节，降低入门门槛，快速见成效
  1. 资深视角：非万能，生产级软件需兼顾安全、可维护性、架构
  1. 价值落地：主打快速原型、创意验证、提效，不替代传统软件工程

📌 必备技能

Prompt 设计、代码调试、底层编程、系统架构知识

🚀 能力进阶

简单演示 → 复杂业务逻辑 → 可维护架构 → 高质量软件工程

💡 关键总结

Vibe Coding 是「低门槛入门+高上限进阶」模式，代码质量最终取决于使用者技术能力，核心是迭代优化，而非一次性完美生成。

02 企业级SDLC（软件开发生命周期）

一、核心概念

SDLC（Software Development Life Cycle，软件开发生命周期）是软件从立项到运维迭代的完整流程，核心特点是持续循环、永不停止，是企业级研发的标准化流程框架。
传统企业SDLC的核心特征：
强规划 + 强文档 + 强流程 + 强审批 → 稳定但慢，适合高合规场景

二、SDLC 7大核心阶段（完整流程）

01 业务规划与立项（Planning）

  • 核心问题：是否值得做？ROI（投资回报率）是否合理？资源是否匹配？
  • 产出物：立项书、Roadmap（产品路线图）
  • 阶段目标：从业务视角评估项目可行性，明确项目方向与资源投入

02 需求分析与PRD（Requirements）

  • 核心问题：用户是谁？业务目标是什么？功能边界是什么？
  • 产出物：PRD（产品需求文档）、SRS（软件需求规格说明书）
  • 阶段目标：明确产品功能、用户需求与业务价值，为后续开发提供依据

03 系统设计（System Design）

  • 核心工作：模块拆分、数据库设计、服务调用设计
  • 产出物：HLD（高层设计文档）、LLD（详细设计文档）、API接口文档
  • 阶段目标：将需求转化为技术架构，明确系统实现方案

04 开发实现（Implementation）

  • 核心工作：前后端开发、Code Review（代码评审）、CI构建
  • 核心特点：基于Git Flow / MR（Merge Request）的协作开发模式
  • 阶段目标：按照设计方案完成代码开发，保障代码质量

05 测试验证（Testing）

  • 核心测试类型：单元测试、集成测试、回归测试、UAT（用户验收测试）
  • 关键提示：缺陷修复成本随阶段推进指数级升高，测试越早介入成本越低
  • 阶段目标：验证软件功能、性能、安全性，保障产品质量

06 上线交付（Deployment）

  • 核心工作：灰度发布、多环境隔离、审批流程
  • 产出物：Release Note（版本发布说明）
  • 阶段目标：安全、稳定地将软件交付给用户，降低上线风险

07 运维与迭代（Maintenance）

  • 核心工作：Bug修复、性能优化、安全补丁
  • 循环逻辑：新需求进入下一轮迭代，开启新的SDLC周期
  • 阶段目标：保障系统稳定运行，持续优化产品体验

三、各阶段补充说明

阶段
核心关注点
关键产出
Planning
项目可行性、ROI、资源匹配
立项书、Roadmap
Requirements
用户画像、业务目标、功能边界
PRD、SRS
System Design
架构设计、模块拆分、接口设计
HLD/LLD、API文档
Implementation
代码开发、代码评审、CI/CD
可运行的代码版本
Testing
多维度测试、缺陷修复
测试报告、验收报告
Deployment
灰度发布、环境隔离、上线审批
Release Note
Maintenance
系统运维、问题修复、需求迭代
迭代计划、优化方案

四、关键补充

  1. 迭代循环：SDLC不是一次性流程，运维阶段的新需求会进入下一轮迭代，形成持续优化的闭环
  1. 传统企业模式特点：强流程、强审批保障了合规性与稳定性，但研发效率相对较低，更适合金融、政务等对合规要求高的行业
  1. 缺陷成本规律：测试阶段发现并修复缺陷的成本，远低于上线后修复的成本，因此测试环节是SDLC的关键质量保障

五、流程总览

业务规划与立项 → 需求分析与PRD → 系统设计 → 开发实现 → 测试验证 → 上线交付 → 运维与迭代 → 新需求进入下一轮

03 Vibe Coding 研发经验

一、核心总纲：大道至简

核心原则：开发方式必须取决于产品复杂度与未来迭代需求，技术服务于业务，而非本末倒置。

二、三大核心模块

① 需求是第一驱动力

  • 核心判断维度：
      1. 需求是否明确？
      1. 是否有清晰的验收标准？
      1. 功能拆分是否合理？
  • 关键结论：产品需求的清晰度，直接决定AI能否被「用对」，是所有开发工作的前提。

② 技术只是辅助

  • 技术工具定位：Skills、MCP、自动代码生成等技术，本质是效率提升辅助工具
  • 核心边界：
      1. 无法解决「定义不清的需求」
      1. 不能替代专业的需求分析工作
  • 风险警示：需求不清晰才是最大的开发成本，盲目用技术工具只会放大问题

③ 未来迭代与可维护性

  • 产品的核心属性：产品需要持续迭代，包含：
      1. Bug 修复
      1. 用户反馈优化
      1. 新功能展开 / 性能改进
  • 核心要求：开发时必须优先保证代码的可维护性和可理解性，为长期迭代留足空间

三、最终行动准则

❌ 禁止行为：不要盲目追求自动化开发、Skills、MCP 等技术模板，避免技术炫技 ✅ 正确流程：先理清需求，再选择合适的开发方式，让技术服务于业务目标

04 Cursor

四种模式

notion image
notion image
notion image

MCP 使用Linear做任务管理

notion image
notion image
notion image
notion image
notion image
为了构建AI驱动的自动任务管理需要使用 Rules 搭配 MCP 来做自然语言的触发
自定义创建 Rule
不要自己写，让ai写，先给官方链接问什么是rule，获得rule上下文，然后让ai创建rule

Rule

notion image
notion image

使用经验分享

notion image

📎 参考文章

  • 一些引用
  • 引用文章
 
💡
欢迎您在底部评论区留言，一起交流~
]]>