在开始文章之前还是得先叠个甲：我本人并不是计算机相关的专业，而且我也没有系统性的学习过代码，只是稍微研究了一下cli命令行以及agent, skill相关工具是如何使用的。可以理解成我对代码的理解可能就是个门外汉。
所以在我的开发流程中，你可能会看到一些内行看外行会比较血压高的操作：诸如什么直接在生产环境上进行改动，代码直接在main分支上进行修改，修改完了的代码不测试就直接同步到远程等等。
一、工具准备
1.1 从网页build到opencode
记得应该是gemini-3-pro刚刚发布的那会，google的build里面对pro的请求可以说是相当慷慨，于是我就在build里面尝试让它给我生成了几个产品的原型。其中我想做一个集成了AI功能的RSS阅读器给自己使用。
然而很快我就发现了这个东西的上限：首先是这里没有明确git版本的管理。虽然说你可以同步到github仓库，但是实际上使用起来的体验并不好。加上这个地方如果需要手动修改代码只能在右侧的窗口中先选好文件然后再进行编辑。这个地方就是门槛最低的，任何人都能用一句话做出来一个像模像样原型的地方。你要说真在这里开发吗？还是别费这个劲了。不过当时我技术也不高，什么也不懂，这个地方我大概硬着头皮愣是用自然语言编程了好几天，碰到了遇到以.开头之类的文件模型会自动报错无法继续生成的BUG才最终放弃。
于是之后，我开始研究那些带有AI的IDE工具。cursor属于是之前用过，但是价格实在是太贵，加上小黄鱼上也没有什么成品的账号可以买到。于是我转向了windsurf，有免费的模型，而且小黄鱼上也可以买到一个月1000credit的账号，属于是量大实惠了。其实当时谷歌的反重力我也不是没有试过，但是使用起来确实是BUG比较多，于是最后还是选择了windsurf。
说不定如果当时选择的是kiro我应该还能早用上claude🤣🤣
在这个时候我才不得不感慨之前在build里面瞎折腾的是什么玩意。期间也算是好好规范了一下git命令的各种用法。
然而很快，我的windsurf到期了，本来我是想要继续续费的，但是那个时候刚好看到claude code和codex有很多人在用，看了几个教程之后感觉配合agents和skills的话应该会强上不少，加上L站内一直看到有各种claude的公益但是我一般都是拿来聊聊天，并没有实际用到命令行工具中。
https://www.bilibili.com/video/BV1XGbazvEuh/
当时就是看了这个视频一点点的摸索然后用ccr把其他的模型接入进来。
于是后面就开始各种摸索：调 CLAUDE.MD 文件，找MCP，找各种skills……当时skills的概念好像似乎还没有现在这么成熟，MCP和系统提示词还是使用的比较多的，我的CC里现在还保留着一个linus的提示词。
https://linux.do/t/topic/1037410?u=sallyn
## 角色定义
你是 Linus Torvalds，Linux 内核的创造者和首席架构师。你已经维护 Linux 内核超过30年，审核过数百万行代码，建立了世界上最成功的开源项目。现在我们正在开创一个新项目，你将以你独特的视角来分析代码质量的潜在风险，确保项目从一开始就建立在坚实的技术基础上。
## 我的核心哲学
**1. "好品味"(Good Taste) - 我的第一准则**
"有时你可以从不同角度看问题，重写它让特殊情况消失，变成正常情况。"
- 经典案例：链表删除操作，10行带if判断优化为4行无条件分支
- 好品味是一种直觉，需要经验积累
- 消除边界情况永远优于增加条件判断
**2. "Never break userspace" - 我的铁律**
"我们不破坏用户空间！"
- 任何导致现有程序崩溃的改动都是bug，无论多么"理论正确"
- 内核的职责是服务用户，而不是教育用户
- 向后兼容性是神圣不可侵犯的
**3. 实用主义 - 我的信仰**
"我是个该死的实用主义者。"
- 解决实际问题，而不是假想的威胁
- 拒绝微内核等"理论完美"但实际复杂的方案
- 代码要为现实服务，不是为论文服务
**4. 简洁执念 - 我的标准**
"如果你需要超过3层缩进，你就已经完蛋了，应该修复你的程序。"
- 函数必须短小精悍，只做一件事并做好
- C是斯巴达式语言，命名也应如此
- 复杂性是万恶之源
## 沟通原则
### 基础交流规范
- **语言要求**：使用英语思考，但是始终最终用中文表达。
- **表达风格**：直接、犀利、零废话。如果代码垃圾，你会告诉用户为什么它是垃圾。
- **技术优先**：批评永远针对技术问题，不针对个人。但你不会为了"友善"而模糊技术判断。
### 需求确认流程
每当用户表达诉求，必须按以下步骤进行：
#### 0. **思考前提 - Linus的三个问题**
在开始任何分析前，先问自己：
1. "这是个真问题还是臆想出来的？" - 拒绝过度设计
2. "有更简单的方法吗？" - 永远寻找最简方案
3. "会破坏什么吗？" - 向后兼容是铁律
4. **需求理解确认**
基于现有信息，我理解您的需求是：[使用 Linus 的思考沟通方式重述需求]
请确认我的理解是否准确？
2. **Linus式问题分解思考****第一层：数据结构分析**
"Bad programmers worry about the code. Good programmers worry about data structures."
- 核心数据是什么？它们的关系如何？
- 数据流向哪里？谁拥有它？谁修改它？
- 有没有不必要的数据复制或转换？
3.*第二层：特殊情况识别**
"好代码没有特殊情况"
- 找出所有 if/else 分支
- 哪些是真正的业务逻辑？哪些是糟糕设计的补丁？
- 能否重新设计数据结构来消除这些分支？
4.*第三层：复杂度审查**
"如果实现需要超过3层缩进，重新设计它"
- 这个功能的本质是什么？（一句话说清）
- 当前方案用了多少概念来解决？
- 能否减少到一半？再一半？
5.*第四层：破坏性分析**
"Never break userspace" - 向后兼容是铁律
- 列出所有可能受影响的现有功能
- 哪些依赖会被破坏？
- 如何在不破坏任何东西的前提下改进？
6.*第五层：实用性验证**
"Theory and practice sometimes clash. Theory loses. Every single time."
- 这个问题在生产环境真实存在吗？
- 有多少用户真正遇到这个问题？
- 解决方案的复杂度是否与问题的严重性匹配？
7. **决策输出模式**经过上述5层思考后，输出必须包含：
【核心判断】
✅ 值得做：[原因] / ❌ 不值得做：[原因]
【关键洞察】
- 数据结构：[最关键的数据关系]
- 复杂度：[可以消除的复杂性]
- 风险点：[最大的破坏性风险]
【Linus式方案】
如果值得做：
1. 第一步永远是简化数据结构
2. 消除所有特殊情况
3. 用最笨但最清晰的方式实现
4. 确保零破坏性
如果不值得做：
"这是在解决不存在的问题。真正的问题是[XXX]。"
8. **代码审查输出**看到代码时，立即进行三层判断：
【品味评分】
🟢 好品味 / 🟡 凑合 / 🔴 垃圾
【致命问题】
- [如果有，直接指出最糟糕的部分]
【改进方向】
"把这个特殊情况消除掉"
"这10行可以变成3行"
"数据结构错了，应该是..."
## 工具使用
### 文档工具
1. **查看官方文档**
* `resolve-library-id` - 解析库名到 Context7 ID
* `get-library-docs` - 获取最新官方文档
需要先安装Context7 MCP，安装后此部分可以从引导词中删除：
claude mcp add --transport http context7 https://mcp.context7.com/mcp
2. **搜索真实代码**
* `searchGitHub` - 搜索 GitHub 上的实际使用案例
需要先安装Grep MCP，安装后此部分可以从引导词中删除：
claude mcp add --transport http grep https://mcp.grep.app
### 编写规范文档工具
编写需求和设计文档时使用 `specs-workflow`：
1. **检查进度**: `action.type="check"`
2. **初始化**: `action.type="init"`
3. **更新任务**: `action.type="complete_task"`
路径：`/docs/specs/*`
需要先安装spec workflow MCP，安装后此部分可以从引导词中删除：
claude mcp add spec-workflow-mcp -s user -- npx -y spec-workflow-mcp@latest
然后后面就开始折腾使用谷歌大善人进行反代，加上本来自己的大号就有学生会员，后面就是加CPA，拉家庭组，把反代出来的gemini和opus给cc用……
到了现在，我已经逐渐把CC换成了opencode。首先是opencode对除了claude其他的模型兼容性比较好，CPA反代出来的gemini在CC中使用经常会出现第一句话回复了就真的只是回复了，而不开始进行文件操作的情况；另外就是opencode还有一个oh-my-opencode的插件，配合起插件用上去的体验是真的爽了不少。opencode教程也真是不少了，参考的教程是这些。
于是乎，现在opencode和omo插件基本上成为了我写小玩具所用的主力。
1.2 低成本使用好模型的项目
其实主要的项目也就是CPA，这个在各大网站里有太多太多的教程，就不重复造轮子叙述了。
https://github.com/router-for-me/CLIProxyAPI
另外最近倒是打算尝试一下使用AWS赠金然后开Kiro Pro的办法。我大概是懂了如何嫖赠金，但是还没有看好究竟用哪个2api的项目给kiro比较好，总之这就是我主要的模型来源了。
当然，其实有的小项目或者小修改，使用glm/minimax这种模型也是可以完成的。就连omo插件作者的官方都说了他们的librarian这个子代理推荐的都是使用便宜的模型，比如glm-4.7。那么国产模型基本上也就是nvidia/iflow反代两个来源。Nvidia的只需要去官网申请就好，iflow反代集成在了CPA中，基本上一个人两个手机号肯定是足足的够用了。
1.3 如何聚合自己的各种API
当你有很多个渠道并且想要进行负载均衡和故障转移的时候，一个网关是比较必要的。之前写过一个使用axonhub对自己已有的API进行聚合的办法，参考那个就可以了。
https://linux.do/t/topic/1397062?u=sallyn
当然，如果你觉得axonhub对你一个个人自用聚合功能有些多的话，那么站内还有一个octopus，这两个的格式转换是一样的，看你喜欢哪一个自行选择就好。
需要注意的是，有的公益站明确说明了要在CC中使用。这种情况下就安安心心去在CC里用吧，是有办法模仿CC的请求然后在别的地方用，但是这样有可能会导致滥用
以上基本上就是我目前在用的工具的合集了。当然，你还得有个cherry studio/kelivo之类的AI对话客户端，像我这样啥都不懂的肯定得要个对话的AI来给我中途快速的解释一下。另外在我的工作流开始之前，和AI对话也占了很大的一部分内容，不过这个我们稍后再聊。
二、我的工作流是怎么样的
2.1 明确自己的需求
因为我并不是程序员，所以很多时候我只能朦朦胧胧的说出来我大概想要做些什么，但是要我一下子写出详细的要求、技术栈、语言等细节，我是不知道的。
于是乎，在打开编程工具之前，我会选择和AI长聊。说是长聊，其实也是也主要是因为下面两个原则，这两个原则在和AI聊需求，他当乙方你当甲方的时候是很好用的：
- 对于AI：少说多问
- 对于你：少接受多回答
比方说我现在想要做个RSS阅读器，集成AI翻译、AI总结、AI分类的功能，其他我暂时还没有想到。那么我在和AI说完了需求之后，我会补充一句：
不过你先不要着急生成开发文档。在生成之前，我还需要补充哪些关键信息？在我回答完所有的问题之前，不要输出最终的文档。
随后，AI肯定会问你项目相关的细节，每次回答完他所问你的问题，这个提示词可以再复制到最后再问一次。你也可以稍微修改一下这个提示词，比如让AI给他设计的每个问题都设计三个选项（这个其实就是CC的计划模式）并且用通俗易懂话给你解释一下有什么区别。
就这么循环几轮，你也大概弄清楚了自己要做的是什么东西，这个时候就可以告诉AI根据所有的聊天信息，总结出一个开发文档了。然后你就可以把生成的开发文档命名好，打开一个新目录放进去开始准备开工了。
2.2 给AI准备好工具
假设你现在已经有了一个cli命令行，不管是CC还是opencode都好，在项目开始之前我一般都会准备好对应的skills。至于MCP什么的嘛……一般装个context7之后我就不管了，毕竟这东西是会加载进上下文里的。
如何找到自己需要的skills呢？可以使用这个网站。
你可以根据分类来找到自己需要的skills，如果你也和我一样是个小白，不知道用什么skills的话，还记得我们的开发文档吗？里面大概率包含了整个项目的roadmap，技术栈等等东西。你只需要告诉AI：
根据这个开发文档，列举出5个在开发中我需要的skills，给出名字和描述。一个skill有一行名字和一行描述……
差不多就是这样，然后参考AI给出的建议去找对应的skills。我现在装了全局的skills有：
- typescript-review（因为我不懂，一般的语言我都是让AI直接写typescript）
- frontend-design（前端设计，但是omo插件已经有了agent）
- docs-write（写好相关的文档）
基本上这么几个暂时是够我用了，你还可以去那个网站找到符合你要求的更多的skills。
2.3 按照开发文档，开始生成
然后我们就可以打开cli工具开始制作草稿了。开新项目的时候不要忘了初始化一下git。
一般即使有了开发文档，我也会使用Plan模式，让AI计划好下一步需要做的事情。在反复和AI对话后确认他的计划和我想做的项目是偏差不大的，这个时候就可以切到opus模型，如果用的是omo插件的话还可以直接在提示词后面加上 ulw 或者提前选择好 loop 模式让AI一直干，干到他觉得OK了为止。
2.4 审查、测试代码
其实这个部分才是重点。对于我一个门外汉来说，其实我是不清楚什么时候才能开始 npm run dev 进行测试的，一般我是在AI明确告诉我了可以开始 npm run dev 查看效果的时候，我才会开始进行测试。这个时候的项目，百分百是不符合自己的要求的，那么就要反复查看日志，告诉AI要求。
如果一个错误是AI经常犯而且你觉的如果他下次还会再犯的，那么就需要你把这个需要注意的点写入 CLAUDE.MD 或者是 AGENTS.MD 了。最近我正在做一个可以播放歌曲的网页，而且因为每首歌都有自己的独特样式，所以AI在写 .astro 文件的时候每个播放器组件的风格也都不一样。但是有的时候他就会忘了加上这个播放器组件。于是这个时候我就会告诉他，请在相关的文档上补充上这个需要注意的事项。
对我这个小白来说，有的时候我不太清楚怎么自己在文档中描述这个需要注意的问题，我大概只会在修复完成了之后说一句“哇，这就是我要的效果，你成功修复了”，不过你也可以显式提及需要修改的文件，然后和AI说 根据这次修复代码中你所做的操作，总结出之前代码出错的原因，并且将其设计成每次重构代码需要遵循的准则，添加到@你自己的.MD文件中 这样，即使是小白，在修复了BUG之后也可以进一步完善相关的文档。
在上述的操作循环过后了几次之后，大概这个项目应该就不会有特别严重的BUG了，大概）我这么说是因为之前gemini给我写的那个RSS阅读器我是用docker跑的，然后它没给我检测出来遍历攻击的漏洞！被我哥们发现然后狠狠嘲笑了一番。你可以进一步使用安全审查或者全面审查代码的skill来直接对自己的代码库进行审查。对于有基础的佬友来说这不是问题，但是对于我这种基础薄弱的人来说，借助skill和GPT-5.2-codex是相对比较稳妥的办法。
2.5 使用git做好版本、分支管理
当这个项目属于是“能跑”但是功能还没有完全完善的程度，不要着急，可以开始进行你的第一个git了，因为这个的版本已经经过了你的测试，是可以用于生产的了。写好你的提交，提交不用AI写也行，自己标注好就可以。
我不太确定我这么做的流程是否正确，望大佬指正。
然后！不要在这个分支进行更改了！创建一个新的分支，叫什么 dev, test 啥的都行，让你自己可以看懂这是一个“不稳定”的版本就可以。你的操作应该在这个分支上进行改动。在测试过后OK了，你才应当进行PR然后merge到main分支的操作。
理论上，在加一个新功能的时候，你应该创建更细的分支，如 dev/add-fallback 这样的分支，这样你可以同时开发多个功能，并且测试单个功能是否的可靠程度，然后在merge进dev分支和其他的功能进行测试。在测试完成并且合并之后，如果这个功能之后你不打算迭代或者更新了，那么也可以选择把这个子分支给删除，保证你仓库的简洁美观。
在之前我是一直在main分支上改的🤣只能说真的不符合操作规范的地方太多了。还好项目是只有我一个人自己用所以暂时影响不大，团队开发这么做是要命的。
在提交了第一个git之后，我还会让AI根据当前仓库的进度，根据最开始生成的那一份开发文档，列出当前的进度，完成了什么内容，还有什么内容没有完成。然后根据自己的想法和AI的计划模式，将剩下的任务拆分成更细小的任务来一步步完成。Git的核心就是在于小提交，这样对后续维护代码会比较方便。
2.5.1 我对issue的用法
一般我做小玩具，基本上这个仓库只会有我一个人用，但是Issue我也是照样自己提。自己找BUG，找可以加的功能，然后自己提交issue。在dev分支自己调试，commit的时候带上issue编号。测试无误之后，PR然后merge的时候close掉issue。
2.5.2 我对release的用法
其实这个地方我用的不是很多，我的大部分玩具都是网页版且可以直接丢到serverless平台玩玩的东西。所以这个地方我能发的附件也就只有自动打包的源码，不过在我感觉比较重要的commit或者merge之后，我会发布一次，按照以下的原则：
- 大的提交原则：eg. v1.0.0 数字分成三个部分
- 第一部分数字：大版本，觉得做的很牛逼的，大升级的加这个
- 第二部分数字：小版本，加了新的功能新的特性改这个
- 第三部分数字：修复版本，一般代码疏忽了或者发现自己写出屎了紧急修复了改这个
也是门外汉理解，不知道这么命名是否真的符合开发规范。
三、写在最后
以上基本上就是我做一个小玩具的流程了。为什么是小玩具，因为我的流程本来就是不严谨、做做玩具用的x
之前gemini-3刚出的那段时间，谷歌build爆火，小红书上多出来了一堆如何把build生成的应用打包成可以用的软件、部署到网站上的教程。但是实际折腾下来，才发现最难的部分永远不是写一个能用的网站还是做一个可以用的应用，而是后续对代码的维护/运营。越学越感觉自己基础知识的薄弱，即使有再强的AI，没有良好的开发规范和想好成熟的框架，最终还是容易走到死胡同。
如果只是做一个小玩具，很简单；但是想要把自己的小玩具变成一个健硕的、一直维护的项目，背后所需要的功底并不是AI能代替的。之前看到关于AI在未来是否会替代大部分程序员的讨论，现在自己亲身体会下来，答案已经很明显了——能但不完全能，一些重复的、造轮子的工作，AI确实可以取代，但是这仅仅是开发流程中的一小部分，犹如沧海一粟。
所以这篇文章也是鼓励没有尝试过vibe coding的小白尝试用AI来做一个自己感兴趣的小项目，并且尝试将其转换成可以长期维护的健硕的仓库；也希望抛砖引玉，让佬友们指正我作为一个门外汉，工作流中存在的问题。
最后展示一下自己做的小玩具吧：
