#目录结构

15小时前

和朋友聊到“前端目录结构重构”话题，出现个很有意思的观念分歧。他是资深的工程师，他的做法是：根据自己的经验定义一套目录结构规范，后续 Agent 基于这套规范来重构。可以认为，这是结对编程的 Vibe Coding 流派。我的思路是：我认为未来 100% 代码会由 AI 来写，那“好的目录结构”应该指“对 Agent 检索友好的结构”而不是“对人类检索友好的结构”。于是，我让 Agent 生成 4 套“以 Agent 为受众的目录结构”，再生成 60 条测试用例，每条用例包括： - 一个开发中会问的问题 - 问题的答案比如： - 问题：如果要新增一个全局复用的空状态组件，应该先放在哪类目录，而不是塞进某个 feature 里？ - 答案：回答应优先定位到共享 UI 或共享反馈能力，而不是任何单一业务 feature 。若回答把全局复用组件放进学生、学校等具体业务目录，则不算正确验收标准包括 3 个维度： - 首跳成功率：面对一个自然语言问题，agent 第一反应是否先进入最合理的目录/文件类别 - 收敛成本：从首跳到找到关键文件，需要多大的搜索范围和多少绕路 - 边界判断：能否正确区分相邻层的职责 Agent 先基于 4 套方案并行跑 4 份重构，再为 5 个环境（4个重构 + 1个原始结构）跑用例打分，最后选分高的。最终分最高的方案仅仅是「在原始架构上强化了二级目录治理」，比如 components 下再按类型细分为： - page - ui - feedback 整个过程 Agent 跑了 4 个小时，花了 100刀。这就是 Agent First 的 Harness Engineering 流派。你更看好哪种观念？

#前端开发 #目录结构 #Vibe Coding #人工智能 #编程规范

5天前

为什么别人写的 Skill 装上就能用，自己写的怎么调都不对？后来慢慢发现——问题真的不在 YAML，也不在目录结构，而是在“你到底在设计什么”。以前写 Skill，本质就是在写一段“更长的提示词”。但这玩意儿有个致命问题：如果没有在设计“行为”，那只是在描述“期望”。AI 听懂一部分，但执行的时候很容易跑偏。看了 Google 那篇总结之后，我有一个很强的共鸣：Skill 本质不是 prompt，而是一个“工作模式”。比如你让它写代码规范，其实不是在让它“生成内容”，而是在让它“遵守规则”（Tool Wrapper）。让它写报告，也不是让它自由发挥，而是让它“按模板填空”（Generator）。让它帮你检查代码，本质是“拿 checklist 一条条过”（Reviewer）。一旦用“模式”去想，而不是“我该怎么写提示词”，整个思路会完全变掉。一个很深的体感是：Agent 不缺能力，缺的是“被约束的结构”。你不给结构，它就会用最省力的方式——猜 + 直接输出。这在简单任务上是优势，在复杂任务上就是灾难。所以有两个特别关键的模式： Inversion：强行让它先问清楚再动手（这个我现在几乎必加） Pipeline：用阶段 + 门控，把它锁在流程里，不让它乱跳这两个东西一旦用上，你会明显感觉： Agent 不再是“有点聪明但不稳定”，而是开始像一个“能被管理的人”。还有一个我自己的总结：Skill 写得好不好，本质不是你写得多复杂，而是你有没有“选对模式”。很多人一上来就想搞复杂 Pipeline，其实完全没必要。我反而建议：先做 Tool Wrapper（最立竿见影）再做 Reviewer（复用性极高）然后再看 Generator / Inversion 最后才是 Pipeline 你会发现，一旦你脑子里有这几种“套路”，写 Skill 就不再是试错，而是在做设计决策。说白了就是一句话：以前你是在“写 prompt”，现在你是在“设计一个小系统”。

#Skill设计 #YAML #目录结构 #行为设计 #谷歌总结