16. 看见下一步需要哪张地图
这本书只带着做完了一个低风险的小工具。往后做更复杂的东西，需要补的知识不是一张一次列全的书单。更好用的办法是反过来：看当前的项目冒出了什么信号，信号指向哪张地图，就翻哪一张。
从信号出发，不从名词出发
Section titled “从信号出发，不从名词出发”「该学数据库吗」「要不要学后端」这类从名词出发的问题，很难回答，因为脱离了具体项目。换成从信号出发就清楚多了：不是「该不该学 X」，而是「出现了什么现象，说明该补 X 了」。下面四个方向，每一个都先给触发信号，再给最短的一个入口，不铺开成课程表。
触发信号：输入从几十行涨到几万行；清洗规则越堆越多，散落在各处；开始需要追溯每一条数据是什么时候、从哪来的。
最短入口：从结构化存储和表格数据处理的基础学起，先解决「数据放哪、怎么按规则批量清洗、怎么留下可追溯的记录」，不必一上来就啃完整的数据库理论。
触发信号：同一个任务要定时反复跑；要一次处理一大批而不是一个；要把几个系统连起来，让一个的输出变成另一个的输入。
最短入口：从定时任务和脚本编排的基础学起，再学怎么调用别的系统提供的接口。目标是让重复的流程能自己跑起来，而不是每次手动触发。
Web 应用方向
Section titled “Web 应用方向”触发信号：需要登录账户；多个人要共享同一份状态；需要服务端逻辑，而不只是一个打开就用的静态页。
最短入口：这一步通常跨过了第 15 章说的「需要协助」那条线。先理解前端、服务端和数据库各自负责什么，再决定哪部分自己做、哪部分引入专业能力。共享状态和账户体系涉及安全，不建议一个人硬扛。
给 Web 应用补一层前端设计
Section titled “给 Web 应用补一层前端设计”Web 应用方向还会出现另一类信号：功能已经能跑，但页面看起来像把常见组件拼在一起；换一个产品名称，界面仍然可以原样套用。这时可以把前端设计当成一项独立工作来处理。
frontend-design 是 Anthropic 官方插件目录中的一个可选插件，面向 Claude Code 的前端界面设计与生成。它的目标不是规定一种固定风格，而是让界面从具体主题、目标用户和页面任务出发，形成有辨识度、能解释的视觉方向。插件页面给出的示例包括音乐流媒体仪表盘、AI 安全初创公司落地页和支持深色模式的设置面板。
如果使用 Claude Code，插件页面提示的安装入口是：
/plugin install frontend-design@claude-plugins-official这不是本书主线的必需工具，也不代表 CodeBuddy IDE 自动支持 Claude Code 插件。没有插件时，按下面的设计流程照样可以完成前端页面。
先写设计计划，再写界面
Section titled “先写设计计划，再写界面”把页面交给 AI 之前，先交给它一份小型设计计划。计划至少包括四项：
- 主题、用户和核心任务：页面服务谁，用户打开后最重要的一件事是什么。设计素材从产品本身的材料、工具、术语或视觉惯例中来。
- 颜色和字体：定义 4 到 6 个有名字的颜色，说明各自用途；区分展示字体、正文字体，以及需要时使用的数据字体。
- 布局概念：用一句话描述信息结构，再画一张简单的 ASCII 线框图，先比较构图，后决定组件。
- Signature 元素：指定一个最值得记住的视觉或交互选择，把主要审美风险集中在这里，其他部分保持清楚和有纪律。
写完计划后做一次替换检查：把产品主题换成另一个同类产品，方案仍然完全成立，说明它还太通用。常见的统计卡片堆叠、机械编号、通用渐变和到处出现的圆角卡片都需要重新问一遍：它们传递了什么信息，服务了哪个任务。
评审生成结果，而不是只看代码
Section titled “评审生成结果，而不是只看代码”构建完成后，检查这几件事：Hero 区域是否直接表达页面主题；字体、颜色和布局是否仍然来自设计计划；编号、标签和分隔线是否表达真实关系；动画是否有明确目的；移动端是否能使用；键盘焦点是否清楚；用户开启 prefers-reduced-motion 后，动效是否会减少。
文案也属于设计的一部分。按钮名称应说明点击后的结果，同一操作在按钮和成功提示里使用同一术语；错误信息说明发生了什么以及如何修复；空状态给出下一步行动。完成评审后，主动删掉一个不服务于页面任务的装饰或效果。
参考：Frontend Design 官方页面、frontend-design 插件源码与 SKILL.md。本节内容按 2026 年 8 月 3 日的页面和源码核对。
Agent 方向
Section titled “Agent 方向”触发信号：想让 AI 基于自己的私有资料回答；想让它自动完成需要多步的任务。这个方向名词最多，容易被唬住，逐个说清各自解决什么、不解决什么：
- RAG（检索增强生成）：先从提供给它的资料里检索相关内容，再让模型据此回答。解决的是「模型不知道这些私有资料」。不解决「资料本身是错的」，喂进去错的，答出来也是错的。
- 向量检索：按语义相近来找内容，而不是按关键词字面匹配。解决的是「说法不同但意思相近也能被找到」。不解决需要精确、逐字匹配的场合，那种用普通查找更合适。
- 微调：用一批例子把模型在某类任务上的输出风格和格式调稳。解决的是「输出风格不稳定」。不解决「缺知识」，缺知识是 RAG 的事；而且微调成本和门槛都比前两者高，通常是最后才考虑的选项。
这三样的原理和用哪家模型无关。真要举例，用 GLM、DeepSeek、Kimi 这类都可以，换一个模型，上面每一条的分工不变。先判断自己的信号对应哪一样，再决定要不要碰。
把这些整理成一张路线图：左边是自己项目里已经出现或可能出现的信号，右边是每个信号对应的那一个最短入口。它不求全，只求「下一步该翻哪张地图」这一个问题有答案。真正开始走某个方向时，还会遇到卡住的问题，下一章讲怎么把问题带出去、问对地方。