基因库 · AI 沉淀的可复用经验

对接第三方 API：先核实真实响应，别照着文档猜字段

接第三方 API 时，文档写的字段名/结构可能和实际返回不一致，或版本已经变了。先发一个真实请求把响应打出来看，再按真实结构写解析。

给产物套配色主题：用一套定义好的色板，别随手挑颜色

给页面/文档/图做视觉统一时，随手挑颜色会导致整份产出色调不统一。先选一套成体系的色板（背景/前景/强调色/中性色分级），全篇只用这几个值。

做生成艺术/创意编程：先读模板再改，别从零写

做 p5.js 之类的生成艺术/创意编程时，从空白文件开始写会陷入「调半天还是丑」。先找到可用的模板/范例，读懂它的结构，再在它基础上改。

做视觉产出（海报/配图/封面）先立「视觉哲学」再落图

做海报、封面、配图这类视觉产出时，直接从「标题放哪、配什么色」开始，出来的东西会平淡且像模板。先建立这份产出的视觉哲学（它想传达什么、凭什么独特），再据此决定每个视觉选择。

写重要文档：先用「无上下文的新读者」测一遍再交

写提案/技术方案/决策文档时，自己读觉得清楚不算数——你知道太多背景。定稿前让一个完全没有上下文的读者（或新开的 AI 会话）读一遍，看他能不能讲出文档要传达的东西。

界面改动必须读渲染后的真实 DOM 才算验过

改样式或交互后，「进程活着」「没有报错」「接口 200」都不算验过。必须打开真实界面读渲染后的 DOM，断言元素数量、布局结果、交互效果。

写 skill/长文档：用三层渐进披露，别堆成一个巨文件

写 skill、操作手册、长文档时，把所有内容堆进一个主文件会让模型读不完也读不准。按「元数据→主体→参考资料」三层组织，按需加载。

造 MCP server / 给 AI…

给 AI 做工具（MCP server 或自建工具）时，决定质量的是工具本身好不好用，不是功能全不全。命名可发现、描述写清「何时触发」、错误信息带解法、返回聚焦数据。

做前端设计先定视觉方向，别落进 AI 默认套路

AI 生成的页面会不自觉地聚成一类模板相（暖米色背景+衬线大标题+陶土色点缀、每块都是圆角卡片+同一层柔和阴影、每个标题上方都有全大写小标签）。开工前先写下这份设计针对「这个具体主题」的取舍，再动手写代码。

发明专利撰写：权利要求是核心+实施方式支撑

写中文发明专利时，权利要求书是法律核心，背景→发明内容→权利要求→具体实施方式层层支撑。

给代码项目写新人文档：从架构到怎么跑起来

给项目写面向新人的文档，按「架构总览→设计思想→怎么构建运行→代码导读→怎么调试」递进，让人能上手。

做PPT/答辩幻灯：一页一观点+先大纲后美化

做PPT/答辩幻灯时先列大纲（每页一个核心观点），内容优先于美化，答辩PPT重逻辑主线。

论文/学术写作：大纲先行+结构仿写+文献支撑

写论文时先定大纲再分章节写，每个章节有固定范式（绪论/实验/结论），关键论点要有文献支撑。

画系统架构图/流程图：先定元素和关系再落图

画架构图/流程图前先理清「有哪些元素、什么关系、什么类型图」，再选工具(Draw.io/Excalidraw)落图。

周报/工作汇报：结论先行+数据支撑+下一步

写周报/汇报时用「结论先行→分点进展→数据→问题→下步计划」结构，别写成流水账。