Appearance
进阶排查指南（课后阅读）
一、界面/样式问题不知道怎么说
▍用途：提供即查即用的 UI 描述词汇与标准化提问句式，专治"想改但不会说"。
绝大多数人不是做不出东西，而是看着成品总觉得哪里不对，却憋不出一个词。本章节不教你设计理论，只给你够用的表达词——想改哪里，把对应词往 prompt 里一放即可。
动作一：先定"方向感"（风格方向）
| 你想要的整体感觉 | 直接把下面这些词丢给 AI |
|---|---|
| 简约专业 | 简洁、克制、信息优先、层次清楚 |
| 温暖友好 | 有人味、容易交流、轻松、不生硬 |
| 轻微科技感 | 清爽、数字感、未来感一点点、别炫技 |
| 更像作品 | 不像默认模板、有主次、有视觉重点 |
动作二：再说"颜色"（配色表达）
| 想表达什么 | 可以这样说 |
|---|---|
| 干净明亮 | 浅色、通透、清爽、留白多 |
| 稳重克制 | 低饱和、偏深、别太跳 |
| 有重点色 | 只留一个主色，其余颜色收住 |
| 不想太花 | 别过多渐变，别让颜色乱跳 |
动作三：再点"结构"（排版与层次词）
| 你看到的毛病 | 可以这样说 |
|---|---|
| 页面太散 | 首屏信息太散，请加强主次关系 |
| 页面太挤 | 区块之间太挤，请增加留白和呼吸感 |
| 看不出重点 | 请让名字、一句话介绍和主按钮更突出 |
| 像信息平铺 | 请拉开标题、正文和辅助信息的层次 |
动作四：最后说"行为"（交互与体验词）
| 你想要的效果 | 可以这样说 |
|---|---|
| 让人一眼知道你是谁 | 首屏打开后一眼就能知道我是谁 |
| 让聊天入口更好找 | 请让聊天入口更明显，但别喧宾夺主 |
| 让按钮像真的能点 | 请给主要按钮明确反馈和真实跳转 |
| 兼顾手机端 | 请确保手机端文字可读、区块不重叠 |
一个很够用的界面表达句式（把空填上就够用了）：
text
现在这个页面的问题是：______
我希望它变成这样的感觉：______
请先只调整这些部分：______
不要动这些部分：______提醒：能说清"问题 + 感觉 + 边界"，AI 基本就能听懂。说不清时，先返回上面四张表挑词，别空着。
二、改动变多、怕改崩
▍用途：提供 Git 最简防御性操作链，确保每次 AI 修改前可一键存档、改错后可一键还原。
基础班用到的 Git 不用管分支和协作，它只帮你做三件事：存档、看历史、回退。把它当成项目的"后悔药"，先存再改，心里就不慌。
第一步：存档（动手前，给当前稳定版打个点）
适合场景：准备做一轮较大改动之前。开口求 AI：
text
我现在准备开始做一轮较大的修改。
请先帮我给当前项目做一个最小存档，作为可回退版本。
只告诉我这次需要知道的步骤，不要展开 Git 理论。第二步：看历史（改了好几轮，想知道还能退回哪）
适合场景：已经改了几轮，想确认之前留了哪些版本。这样问：
text
请帮我查看这个项目目前有哪些存档记录。
我想知道最近几个可回退版本分别是什么。第三步：回退（这一轮改坏了，先回稳定版）
适合场景：布局改崩、内容改乱、页面明显退步。这样说：
text
这一轮修改效果不好。
请帮我回到上一个稳定版本，并告诉我这次回退到了哪个存档点。一张最小心智图：
| 动作 | 把它理解成什么 |
|---|---|
| 存一次 | 给当前版本打一个"能回来"的点 |
| 看历史 | 看看自己之前都留过哪些点 |
| 退回来 | 出问题时回到最近的稳定状态 |
提醒：别等项目已经改崩了才第一次想起 Git。更稳的顺序是——先存一次，再大胆改。
三、涉及 API Key / 环境变量
▍用途：明确环境变量安全红线：哪里存、怎么藏、何时验，避免密钥误提交或明文暴露。
不要求你一次学完整套安全体系，但有几条底线越早建立越好。记住一句话：API Key 不要直接写进代码仓库。
哪里存：.env 创建规范
.env 就是专门放"本来就不该写进代码"的配置值的地方。像这些内容，都该放进去，而不是硬编码在代码里：
- API Key
- 数据库连接地址
- 第三方服务密钥
怎么藏：.gitignore 必加项
.gitignore 的作用很朴素——告诉 Git 哪些文件不要提交进仓库。基础班最该养成的习惯之一，就是确认 .env 这类敏感文件不会被提交出去。检查一下，确保像 .env 这样的文件出现在你的 .gitignore 里。
何时验：上线前密钥检查清单
上线前，逐条对照检查这四件事：
- [ ] API Key 没有写死在源码里
- [ ]
.env这类本地敏感文件没有被提交到仓库 - [ ] 部署平台需要的环境变量已经正确配置
- [ ] 线上缺少密钥时，页面不会假装正常工作
一个很够用的检查提问（不确定有没有放错地方时）：
text
请帮我检查这个项目里是否有敏感信息直接写在代码里。
重点检查 API Key、环境变量和不应该提交到仓库的配置文件。
如果有问题，请告诉我应该怎么调整。提醒：这里只帮你守住最低底线。想系统补认证、权限、安全策略，等后续分享。
四、判断这个需求该不该用 AI 做
▍用途：划清 Vibe Coding 能力边界，避免在不可行方向上空耗时间。
不要神化 Vibe Coding，也别低估它。判断的唯一标准不是"AI 强不强"，而是出错之后代价有多大——代价越低越敢放手试，代价越高越要慢下来。
一张对比表看清能做与不能做：
| 类别 | 典型场景 | 为什么 |
|---|---|---|
| 能做（放心快速试） | 页面生成（主页、活动页、作品集） | 反馈直观，错了就改，迭代快 |
| 文案润色（介绍、标题、提示语） | 结果即时可见，不满意重来 | |
| 调试辅助（查日志、定位报错、改 bug） | 成本低，试错代价小，能快速收敛 | |
| 不能做（硬边界，要谨慎） | 生产级运维（高并发、核心系统） | 牵涉性能、稳定、复杂架构 |
| 合规审计（强审计、金融链路、发证流程） | 不只是做出来，还涉及流程与责任 | |
| 无源数据训练（没有可靠数据来源的任务） | 没数据就没法训练，不能凭空出结果 |
一句话判断标准：
- 出了错，代价主要是"体验不好、继续改" → 适合用 Vibe Coding 起步。
- 出了错，代价会变成"资金损失、隐私风险、严重责任" → 必须谨慎，甚至要更专业的工程与审查流程。
提醒：这不是说 AI 不能参与那些硬边界系统，而是说那些场景不能只靠"先 vibe 一把"来推进。知道什么时候该快、什么时候该慢、什么时候该找专业支持，本身就是成熟之选。