夜雨聆风我不是程序员，但这两个月，我一直在跟代码、终端、AI工具链死磕。
我的本职是工程项目咨询，日常就是编写报告、项目评审、汇报方案；业余主要精力放在投资研究上，拆公司、跟数据、写投研笔记。两件事都绕不开同一个循环：阅读、整理、判断、输出，周而复始。
两个月前，我决定把AI真正搬进这两条工作线里。结果踩的坑，比学到的东西还多。
不只是那种和AI网页对话"根据我提供的材料写个周报"的程度，而是从底层环境开始，认真搭一套能跑通的系统。Windows、WSL、VSCode、Claude Code、Codex、Hermes……一路折腾下来，踩了很多坑，也走了不少弯路。
但正是这些弯路，逼我想明白了一件事：
AI工具越强，越需要人有主线。否则工具不是放大能力，而是放大混乱。
这篇文章，是我两个月实践的一次完整复盘。
第一个坑：把"装工具"当成了"在进步"
一开始，我的逻辑很朴素：哪个工具强就用哪个，哪个模型聪明就换哪个。
于是问题迅速叠加——PowerShell还是WSL？Ubuntu还是Debian？Claude Code装在哪？代理怎么配？Node版本怎么管？GitHub为什么403？
这些问题单看都不大，但叠在一起就变成巨大的认知噪音。每天看起来都在推进，实际上很多时候在原地打转——今天修代理，明天换终端，后天重装环境，大后天又去试新工具。
这就是代码小白最容易掉进的坑：把环境搭建误以为是能力建设。
环境搭建有个危险之处：它会制造"我正在进步"的幻觉。因为你每天都有新问题、新命令、新截图，每天都能解决一点东西。
但真正的问题是：解决完这些，你产出了什么？
文章有没有稳定变好？报告有没有更可复盘？技术排错有没有沉淀成流程？
如果没有，那环境只是环境，不是生产力。
第一个转折：VSCode不是编辑器，是"项目现场"
真正让我开始收口的，是重新理解了VSCode。
以前我以为它就是个写代码的软件。后来才发现，它更像一个项目工作台：左边是文件树，中间是编辑区，下面是终端，旁边可以接AI助手。Git、日志、配置、文档、脚本，全在同一个界面里。
这件事对代码小白尤其重要。
因为小白最大的问题不是不会某个命令，而是上下文经常断掉。文件在这里，终端在那里，聊天窗口里有一段建议，另一个工具里又改了一点配置——最后人被工具牵着走，根本不知道项目到底处于什么状态。
VSCode把这些东西重新归拢到一个现场。你不再在一个个窗口间来回切换，而是在一个项目里看全貌。
这时候，AI工具才不再是漂浮在外面的聊天窗口，而是开始围绕你的项目工作。
最关键的认知：给每个工具一个位置，别让它们抢"主控"
两个月最大的收获之一，是终于不再让每个工具都争夺主控地位。
一开始很容易这样想：Claude Code很强，它是不是主控？Codex能执行代码，它是不是主控？Hermes能编排任务，它是不是主控？如果每个工具都想当主控，结果一定是混乱。
现在我把它们分成了四层：
① VSCode → 施工现场 文件、编辑、终端、Git、日志、配置，所有项目都在这里被看见、被修改、被沉淀。
② Claude / Codex → 具体施工者 Claude擅长复杂判断、写作打磨、架构设计；Codex擅长代码审查、命令执行、工程修复。它们不是抽象地聊天，而是在项目目录里干活。
③ Hermes → 生产调度 它不抢VSCode的位置，也不亲自改文件。它负责组织流程：走哪条workflow？调用哪个skill？输出成公众号文章还是投研报告？
④ skills / agents / templates / logs → 长期资产 工具会换，模型会升级，但沉淀下来的技能模块、模板、案例库，会慢慢变成真正属于自己的东西。
一句话总结：
VSCode管现场，Claude/Codex管施工，Hermes管调度，长期资产沉淀到项目库。
这句话看起来简单，但对我来说是两个月才真正想明白的。
最该投入时间的，不是更多工具，而是3-5个高频skill
收口之后，下一步变得非常明确：先打磨几个高频skill。
什么是skill？别被这个词吓到。它不是什么神秘的技术概念，更像一个可复用的专业工种说明书——你把一个任务的标准、步骤、禁忌、样例、输出格式写清楚，它就从一次性的临时聊天，变成可以反复调用的能力模块。
我目前在打磨的五个：
代码审查skill — 不是"帮我看看代码"，而是固定检查问题等级、错误原因、修复方案、验证命令，每次审查按同一套标准来。
文章打磨skill — 沉淀文风偏好、结构要求、标题规则、首屏钩子、表达禁忌。写公众号不再每次从零开始提醒AI。
投研审查skill — 检查数据来源、核心假设、估值逻辑、风险暴露。投研最怕的不是不会写，而是写出一堆看似专业、实际没有决策价值的话。
技术排错skill — 对小白来说，技术指导最怕一次给十几步。正确方式是一次只走一小步，先判断当前环境，再根据错误反馈推进。
视觉提示词skill — 封面、配图、小红书图文，审美规则也可以沉淀：浅色背景、高对比、知识杂志感，不要赛博朋克，不要纯黑。
先把skill练成，再让agent调用。 顺序不能反。
一个真实的教训：别对"系统感"上瘾
这两个月还有一个很切身的教训。
一旦开始搭工作流，就会忍不住继续扩展。今天接Claude，明天接Codex，后天加Hermes，大后天又想接知识库、MCP、自动化任务、定时报告、多Agent协作……
每个想法单看都合理，合在一起就变成一张过大的网。网越大，维护成本越高，真正产出的东西反而越少。
我现在给自己的提醒是：
系统不是越完整越好，而是越能稳定产出越好。
一个能每周稳定产出一篇好文章、一个投研报告、一个可复用skill的简单系统，比一个理论上包罗万象、实际上天天排错的大系统有价值得多。
工具探索阶段可以宽一点，因为你需要知道外面有什么。但一旦进入收口期，就必须严格——不能因为一个新工具看起来高级就重新开一条战线，不能因为某个环境理论上更优雅就推翻已经能用的主环境。
真正成熟的工作流，不是没有更多选择，而是知道什么时候停止选择。
AI对普通人的真正意义
很多人把AI编程理解成"我不会代码，但AI能替我写"。这个理解不算错，但太浅了。
AI更大的意义，是把原本无法进入的技术世界，拆成了一个个可以理解、可以验证、可以推进的小步骤。
你不一定要马上成为程序员，但你需要慢慢建立几个能力：
看得懂项目结构，知道文件在哪里；看得懂错误信息，知道问题大概属于环境、依赖、网络还是代码；知道什么时候该让AI解释，什么时候让AI执行，什么时候必须自己判断。
这不是传统意义上的"学编程"，而是新一代的技术协作能力。
未来很多人不一定会写大量代码，但会越来越频繁地和AI、脚本、自动化工具、数据接口打交道。那时候真正拉开差距的，不是谁背了更多语法，而是谁能把一个真实问题拆解成流程、资产和产出。
从探索期到收口期
前两个月是探索期。允许折腾，允许换路，允许踩坑。没有这段经历，我不会知道哪些工具真有价值，哪些只是看起来高级。
但现在，我必须进入收口期。
主线已经确定：
VSCode + WSL 作为项目现场；Claude / Codex 作为执行工具；Hermes 作为调度层；所有成果沉淀到 skills、agents、templates、logs 里。
接下来要问的，不是"还有没有更好的工具"，而是"这个系统能不能稳定产出"——
能不能产出一篇文章？能不能打磨一个skill？能不能审查一份报告？能不能把一次经验沉淀成下次可复用的模板？
如果不能，系统还只是玩具。 如果能，它才开始变成生产力。
这就是两个月后我最大的体会：
AI时代，代码小白并不是没有机会。
真正危险的，是永远停留在工具折腾里，以为自己在进步。
工具只是入口，工作流才是底座。 模型只是帮手，判断力才是方向。 环境只是现场，产出才是答案。
我有没有把今天的折腾，变成明天还能复用的能力？
这是我现在每天问自己的话。也是这个号接下来要持续记录的事——不追新工具，不炫技术栈，只关心一件事：一个普通人，怎么用AI建立真正的生产力。
如果你也在走这条路，欢迎关注，我们一起慢慢把路走实。
我是几何构造师，一个非技术背景的AI实践者。这个号记录的不是工具评测，而是一个普通人把AI变成工作方式的真实过程。
