一个互联网产品，是这样从想法变成你手里的产品的——下面按「谁来干这一环」分类，看懂每个角色的行话。
- 产品经理想清楚做什么
- 设计师画出长什么样
- 前后端把它真正做出来
- 测试保证不崩
- 运维让它上线
- 运营让它长起来
- 你 + AI不懂技术也能指挥
- requirement需求说白了就是「要做成什么样」。产品经理把「用户想要什么」翻译成开发能照着做的清单。需求不清楚，后面全白做——所以它是一切的起点。
- user story用户故事用一句大白话描述「谁、想干什么、为了什么」，比如「作为上班族，我想一键点单，这样不用排队」。它逼着大家从用户角度想问题，而不是自嗨堆功能。
- persona用户画像给目标用户画一张「虚拟身份证」：年龄、职业、习惯、痛点。比如「25 岁、爱熬夜、手机不离手的小李」。有了具体的人，做决定时就有了参照——「小李会用吗？」
- pain point痛点用户真正难受、忍不了的地方。抓住痛点的产品才有人用。注意：用户嘴上说的不一定是真痛点，得挖背后那个「烦死了」的瞬间。
- scenario场景用户在「什么时间、什么地点、什么状态」下用你的东西。同一个功能，地铁上单手用和办公室双手用，设计完全不同。脱离场景谈功能都是空想。
- MVP最小可行产品 MVP先做一个「能用、但只有核心功能」的简版，快速上线看看有没有人要，而不是憋大招做半年。MVP 的精神是：用最小代价验证「这事靠不靠谱」。
- PRD产品需求文档 PRD产品经理写给设计和开发看的「施工图纸」，讲清楚每个功能长啥样、点了会怎样。它是团队的「共识合同」，免得做到一半各想各的。
- backlog需求池把所有「想做但还没做」的需求堆在一个清单里排队。资源有限，不可能全做，于是需求池就成了「待办仓库」，按优先级一个个取。
- iteration迭代产品不是一次做完，而是一版一版地改进：先上线 1.0，根据反馈出 1.1、1.2……「小步快跑、持续改」就是迭代。
- priority优先级 P0/P1决定「先做哪个」。P0 = 不做就上不了线的命根子，P1 = 重要但能稍等，往后数字越大越不急。资源永远不够，排优先级是产品经理的核心功力。
- competitive analysis竞品分析研究「别人家同类产品」怎么做的——抄好的、避坑的、找空子。不是抄袭，是站在前人肩膀上少走弯路。
- user research用户调研做之前先去问真实用户：访谈、问卷、观察他们怎么用。目的是别拍脑袋——你以为的需求，常常不是用户真正要的。
- requirement review需求评审需求正式开做前，拉上设计、开发、测试一起「过一遍」，挑毛病、对齐理解、估工作量。评审通过才动手，避免做错方向。
- milestone里程碑项目路上几个关键的「检查点」，比如「3 月底出设计稿、4 月中能内测」。它把一个大项目切成看得见的阶段，方便对进度。
- roadmap产品路线图未来几个月/几个季度「打算做什么」的规划地图。让团队和老板知道「我们要去哪、按什么顺序去」。
- business model商业模式说白了就是「靠什么赚钱」：卖会员、收广告、抽成还是卖货。再好的产品不能持续赚钱也活不下去，所以这是产品的生死线。
- information architecture信息架构 IA把内容「怎么分类、怎么摆」想清楚，就像图书馆把书分门别类上架。架构乱了，用户找不到东西，再好看也没用。
- user flow用户流程图画出用户「从进来到完成目标」走过的每一步，比如「打开→搜索→下单→支付」。提前发现哪一步会卡住、会跑掉。
- prototype原型产品正式做之前的「可点击草图」，用来模拟「点这里会跳到哪」。先用便宜的原型试错，比做完了再改省太多事。
- wireframe线框图只用方块和线画出「东西摆在哪」的骨架图，不上色不修饰。先定布局，再谈美不美。
- fidelity低保真 / 高保真保真度 = 「跟最终成品有多像」。低保真是潦草草图（快、便于改），高保真是接近真实的精致稿（用于最终确认）。先低后高，循序渐进。
- mockup设计稿 Mockup高保真的「效果图」，颜色、字体、图片都到位，基本就是成品的样子。开发照着它还原界面。
- interaction design交互设计设计「用户操作和界面反应」的规则：点按钮有什么反馈、滑动会怎样、出错了怎么提示。好交互让人「不用想就会用」。
- design review设计走查设计稿出来后，团队一起「逐屏检查」：好不好用、合不合规范、开发能不能实现。挑完毛病再交付，减少返工。
- UIUI 界面User Interface，用户「看得见、点得着」的部分——按钮、颜色、图标、排版。UI 负责「好不好看」。
- UXUX 体验User Experience，用户用起来「爽不爽、顺不顺、烦不烦」的整体感受。UI 是颜值，UX 是用着舒不舒服，两者不是一回事。
- design system设计规范把颜色、字体、按钮样式、间距等定成一套「全员通用的标准」，保证整个产品长得像一家人，也让设计和开发不用每次重新发明轮子。
- grid system栅格系统用一套看不见的等宽列（比如 12 列）来对齐内容，就像作业本的格子。东西摆在格子上，自然就整齐、有秩序。
- whitespace留白 / 间距元素之间的「空地」。留白不是浪费，而是让眼睛有地方歇、让重点更突出。挤在一起的界面让人喘不过气。
- visual hierarchy视觉层级用大小、颜色、粗细告诉眼睛「先看哪、后看哪」。标题大、正文小、按钮显眼——用户一眼就知道重点在哪。
- color scheme配色方案一套搭配好的颜色：主色、辅助色、点缀色。配色定调性（活泼/高级/科技），也影响好不好读，是界面的「整体气质」。
- typography字体排印选字体、定字号、调行距的学问。文字占了界面的大半，排得好读起来轻松，排不好再美的设计也累眼。
- alignment对齐【设计四大原则之一】东西的边要对齐在一条看不见的线上。对齐让画面显得「专业、整洁」，乱对齐立刻显得廉价。
- contrast对比【设计四大原则之一】让该突出的更突出：大小对比、颜色对比、粗细对比。没有对比，画面就一团糊、抓不住重点。
- proximity亲密性（分组）【设计四大原则之一】相关的东西放一起、不相关的拉开距离。靠得近的会被大脑自动认为「是一伙的」，分组清楚信息才好读。
- repetition重复（一致性）【设计四大原则之一】同类元素用同样的样式，全程统一。重复带来「一致、可预期」，用户学一次就处处会用。
- fitts law费茨定律目标越大、越近，就越好点中。所以重要按钮要大、要放在手指够得着的地方。手机底部的大按钮就是这个道理。
- hicks law希克定律选项越多，人做决定越慢、越累。所以菜单别堆太多、一次别让用户选太多。「少即是快」。
- millers law米勒定律人脑短期只能同时记住 7±2 个东西。所以信息要分组、分块，别一次塞一长串——电话号码分段写就是这个原理。
- jakobs law雅各布定律用户大部分时间在用别的网站，所以他们希望你的产品「和别人差不多」。别瞎创新基础交互，遵循大家熟悉的习惯反而更好用。
- teslers law特斯勒定律（复杂度守恒）每个产品都有一份「省不掉的复杂」。你不处理，就甩给用户；你多做一点，用户就轻松一点。好设计是「把复杂留给自己」。
- doherty threshold多尔蒂阈值系统响应最好快过 400 毫秒，用户才会觉得「跟得上、不卡」。慢了人就分心、烦躁。这就是为什么加载要做得快、或先给个动画安慰。
- gestalt格式塔原则人脑会自动「找规律、凑整体」：靠近的、相似的、连续的会被看成一组。设计师顺着大脑这个本能排版，用户就觉得「自然、好懂」。
- occams razor奥卡姆剃刀能简单就别复杂，砍掉所有非必要的东西。功能越少越聚焦、越好用。「这个真的需要吗？」是设计师的口头禅。
- error prevention防错原则好设计不是出错后提示，而是「让你压根错不了」。比如删除前先确认、关键字段做格式限制。预防胜于补救。
- feedback即时反馈用户做了操作，界面要马上给回应：点了按钮要变色、提交了要转圈、成功了要提示。没反馈会让人怀疑「我点了吗？坏了吗？」
- pareto80/20 法则80% 的用户只用 20% 的核心功能。所以把精力砸在那最关键的 20% 上，别被一堆「锦上添花」分散。抓主要矛盾。
- aesthetic usability美学可用性效应好看的东西，会被用户「觉得」更好用，也更愿意包容小毛病。颜值确实是生产力——这就是为什么要好好做视觉。
- nielsen heuristics尼尔森可用性原则一套公认的「界面好不好用」的十条体检标准（如状态可见、和现实一致、给用户撤销的机会等）。设计师拿它当checklist自查。
- frontend前端用户「看得见、摸得着」的那一半——你在屏幕上看到的页面、按钮、动画全是前端。可以理解成餐厅的「前厅」：菜单、餐桌、装修都在这儿。
- page页面你在浏览器里看到的一屏内容就是一个页面。点链接换一屏，就是从一个页面跳到另一个页面。
- component fe组件把界面拆成一块块「可重复用的积木」：一个按钮、一个卡片、一个导航栏都是组件。搭好积木再拼成页面，改一处处处生效。
- htmlHTML网页的「骨架」，负责「有什么内容」——这是标题、那是段落、这里放图片。光有 HTML 的网页能看但很丑，像没装修的毛坯房。
- cssCSS网页的「装修」，负责「长什么样」——颜色、字体、布局、间距、动画都归它管。CSS 让毛坯房变成精装房。
- javascriptJavaScript网页的「行为」，负责「能干什么」——点击有反应、表单能提交、数据会更新。它让死页面活起来，是前端的「大脑」。
- framework fe前端框架前人写好的「半成品工具箱」（如 React、Vue），帮你少写重复代码、更快搭界面。不用从零造轮子，站在框架肩膀上做事。
- responsive响应式同一个网页，在电脑大屏、平板、手机上都能自动调整布局、都好看好用。「一套设计，自适应各种屏幕」就是响应式。
- browser浏览器用来打开网页的软件（Chrome、Safari、Edge）。前端代码最终是「跑在浏览器里」给用户看的，所以要照顾不同浏览器的脾气。
- state状态界面「当前的样子/数据」，比如购物车里有几件、按钮是开还是关。状态一变，界面就跟着变。前端很大一部分工作就是「管好状态」。
- routing路由决定「访问哪个网址，显示哪个页面」的规则，就像大楼的门牌号导航。点了「关于我们」就路由到关于页。
- api integration接口联调前端和后端「对接」：前端去后端要数据、后端把数据传回来显示。联调就是双方一起调试「这根管子通不通、数据对不对」。
- compatibility兼容性保证在不同浏览器、不同手机、不同版本上都能正常用。「在我电脑上好好的，到你这儿崩了」常常就是兼容性问题。
- build打包构建把开发时一堆零散的代码「压缩、打包」成浏览器能高效加载的成品文件。就像搬家前把东西装箱打包，到了再展开。
- first screen首屏 / 加载速度用户打开网页后「第一眼多久能看到内容」。首屏越快，跑掉的人越少。慢一秒，可能就流失一批用户，所以前端很看重它。
- backend后端用户「看不见、但真正干活」的那一半——算账、存数据、判断权限都在这儿。就像餐厅的「后厨」：你看不到，但你点的菜都是它做的。
- server服务器一台「24 小时不关机、专门干活」的电脑，放在机房里。你的网站、App 的后端就跑在它上面，随时等着响应用户请求。
- APIAPI 接口前端和后端之间的「传菜窗口」。前端通过 API「点单」，后端通过 API「出菜」。它规定了「能要什么、怎么要、给回什么」。
- endpoint接口地址 EndpointAPI 的「具体窗口编号」，是一个网址，比如 /api/login 管登录、/api/orders 管订单。前端按编号去对应窗口取东西。
- request response请求与响应前端「问一句」（请求），后端「答一句」（响应）——这一问一答是网络世界最基本的对话方式。你刷新页面，背后就是无数次请求和响应。
- HTTPHTTP（GET/POST）前端后端对话用的「通用语言」。GET 是「我来取点东西」，POST 是「我来交点东西」。浏览网页用 GET，提交表单用 POST。
- status code状态码（404/500）后端用数字告诉你「这次请求结果如何」：200 = 成功，404 = 找不到（地址错了），500 = 服务器自己崩了。看到 404 就知道是「东西不存在」。
- business logic业务逻辑「这件事该按什么规则办」的代码，比如「下单要先检查库存、VIP 打 9 折」。它是后端的核心，把现实世界的规矩翻译成程序。
- authentication鉴权（登录）确认「你是不是你」——账号密码、验证码、扫码登录都是鉴权。它是后端的门卫，先验明身份才让你进。
- authorization权限确认「你能干什么」——登录后，普通用户和管理员能做的事不一样。鉴权管「是谁」，权限管「能干啥」，两者配合保证安全。
- middleware中间件夹在请求中间的「流水线工序」，每个请求先经过它处理一道，比如「先记日志、先验登录、先限流」再放行。像进门前的安检通道。
- logging日志程序运行时自动记下的「流水账」：谁、什么时候、做了什么、出没出错。出问题时翻日志，就像查监控录像找原因。
- async queue异步 / 队列把「不用马上做完」的活先排队、慢慢处理，不卡住用户。比如下单后「发短信通知」丢进队列慢慢发，用户不用干等。
- cron job定时任务让程序「到点自动干活」，比如每天凌晨 3 点备份数据、每周一发周报。不用人盯着，设好闹钟它自己来。
- JSONJSON前后端传数据用的「通用格式」，长得像一份结构化的清单（键: 值）。它轻便、人和机器都能读，是网络数据的「普通话」。
- tokenToken（令牌）登录成功后，后端发给你的一张「临时通行证」。之后你每次请求都带着它，后端一看就知道「哦是已登录的你」，不用反复输密码。
- database数据库专门「存数据、并能快速查」的仓库，用户信息、订单、文章全存在这儿。和普通存文件不同，它能高效地「按条件捞数据」。
- SQL / NoSQLSQL / NoSQL两大类数据库。SQL（关系型）像规整的 Excel 表格，适合结构清晰的数据；NoSQL（非关系型）更灵活自由，适合杂乱多变的数据。各有各的用武之地。
- table表数据库里像 Excel 一样的「一张表」，比如「用户表」「订单表」。每张表存一类东西，是数据库最基本的收纳单位。
- field字段表里的「一列」，比如用户表的「姓名」「手机号」「注册时间」。字段定义了「这类数据由哪些信息组成」。
- primary key主键每条数据的「唯一身份证号」，保证不重复、能精准找到某一条。比如每个用户有唯一 ID，靠它就能锁定具体某个人。
- CRUD增删改查 CRUD对数据的四种基本操作：增（添新）、删（去掉）、改（修改）、查（找出来）。几乎所有功能本质上都是在做这四件事。
- index索引给数据建的「目录/拼音表」，让查找快得飞起。没索引就像一页页翻书找，有索引就像查目录直接翻到。数据多了，索引是救命的。
- query查询向数据库「提问要数据」，比如「找出所有上海的、最近 7 天下过单的用户」。查询写得好不好，直接决定快不快。
- cache缓存把「常用、不常变」的数据先存在「手边更快的地方」，下次直接拿，不用每次都去数据库翻。就像把常用文件放桌面而不是每次进档案室。
- migration数据迁移改动数据库结构（加字段、换表）或把数据搬到新地方的过程。像家里重新装修、搬家——得小心别把东西弄丢弄乱。
- backup备份定期给数据「拍快照、存副本」。万一服务器挂了、数据删错了，能用备份恢复。没备份的数据，丢了就真没了。
- consistency数据一致性保证「同一份数据在哪看都一样、不矛盾」。比如你转账后，余额必须立刻对得上，不能这边扣了那边没加。钱相关的系统对它要求极高。
- testing测试上线前「全面挑毛病」，确保功能真能用、不崩。开发负责「做出来」，测试负责「确保它真行」，是上线前的最后一道防线。
- bugBug（缺陷）程序里的「毛病」——该对的算错了、该显示的没显示、一点就崩。Bug 这词来自早期电脑里真卡进一只虫子的故事。修 bug 是开发的日常。
- test case测试用例一条条「该怎么测、预期是什么」的清单，比如「输入空密码，应提示不能为空」。照着用例逐条测，不漏掉边边角角。
- unit test单元测试对最小的代码块「单独验货」，确保每个零件本身没问题。就像汽车出厂前先单独测每个零件，再组装。
- integration test集成测试把各部分「拼起来一起测」，看它们配合时会不会出岔子。单个零件都好，装一起未必好——集成测试就查这个。
- regression回归测试改了新东西后，「回头再测一遍老功能」，确认没把原来好的搞坏。「改 A 坏 B」是常事，回归测试专防这个。
- stress test压力测试故意用「超大流量」猛压系统，看它扛不扛得住、什么时候崩。提前知道极限，免得大促时真用户一来就瘫了。
- UAT上线前验收 UAT正式上线前，让产品方/真实用户「按实际场景用一遍」，确认「确实是我们要的、能交付」。验收过了才敢上线。
- reproduce复现按步骤「把 bug 再次重演出来」。能稳定复现，开发才好定位和修。「我这儿没问题」常常是因为没找对复现步骤。
- gray release灰度发布新版本先「放给一小部分用户」试用，没问题再逐步扩大到全部。万一有坑，只影响少数人，能及时刹车。
- rollback回滚新版本上线后发现出大问题，「一键退回上一个好版本」。它是上线的「后悔药」，让你敢于发布、出事能救。
- algorithm算法解决问题的「一套固定步骤/思路」，比如怎么排序、怎么找最短路。同样的事，好算法又快又省，烂算法又慢又费。
- data structure数据结构数据在程序里「怎么组织摆放」的方式（队列、栈、树、哈希表等）。摆放方式选对了，存取就高效——就像东西分门别类放，比一股脑堆着好找。
- time complexity时间复杂度衡量「数据变多时，程序会慢多少」。它不看具体秒数，而看「增长趋势」：数据翻倍，耗时是翻倍还是翻几十倍？这决定了能不能扛大数据量。
- space complexity空间复杂度（内存）衡量「程序运行要占多少内存」。省内存的程序能在更便宜的机器上跑、能处理更大的数据。和时间复杂度常常要「拿空间换时间」地权衡。
- model模型AI/算法从大量数据里「学」出来的一套规律，用来做预测或判断，比如「根据你看过的推你可能喜欢的」。它是 AI 智能的核心。
- training训练拿大量数据「喂」给模型，让它反复学习、调整，直到学会规律。就像给学生大量例题练习，越练越准。
- recommendation推荐系统根据你的行为「猜你喜欢」并主动推给你的算法，刷视频、逛购物时停不下来，背后就是它。它决定了你看到什么。
- optimization性能优化想办法让程序「更快、更省、更稳」：减少重复计算、加缓存、改进算法。东西能用之后，优化决定它好不好用、扛不扛得住。
- concurrency并发「很多人同时用」的情况。一万人同时下单，系统能不能不乱、不崩？处理好并发，是从「能用」到「扛得住」的关键一关。
- cache strategy缓存策略决定「什么该缓存、缓多久、什么时候更新」的规则。缓存用好了飞快，用错了会让用户看到「过期的旧数据」，是门平衡的艺术。
- Big-O大 O 表示法工程师描述复杂度的「行话记号」，比如 O(n)、O(n²)。它不纠结具体快慢，只表达「随数据增长，代价怎么涨」。听到它，就是在聊效率。
- bottleneck瓶颈定位找出「拖慢整个系统的那一个最慢环节」。系统慢往往是某一处卡脖子，找到并解决它，整体速度立竿见影。木桶能装多少水看最短板。
- deployment部署把做好的代码「放到服务器上、让全世界能访问」的过程。在你电脑上能跑只是第一步，部署上线才算真正「做出来了」。
- go live上线产品正式「对外开放、用户能用了」的那一刻。上线前要测试、要准备回滚方案，因为这一下就面对真实用户了。
- domain域名网站的「门牌地址」，比如 baidu.com。用户记不住一串数字 IP，域名就是给服务器起的好记名字，得花钱注册。
- DNSDNS互联网的「电话簿」，负责把好记的域名翻译成机器用的 IP 地址。你输入网址能打开网页，背后是 DNS 在帮你「查号转接」。
- cloud云服务不用自己买服务器，而是「按需租用」别人（腾讯云、阿里云）机房里的计算资源。像用水电一样按量付费，省心、能随时扩容。
- environment环境（开发/测试/生产）三套隔离的「场地」：开发环境随便改、测试环境专门验货、生产环境是真用户在用的。分开是为了「试错不影响真用户」。
- CI/CDCI/CD（自动化部署）让「代码一提交，就自动测试、自动上线」的流水线。省去手动部署的繁琐和出错，改完推一下，机器自动帮你发布。
- Docker容器 / Docker把程序和它需要的环境「打包成一个标准集装箱」，搬到哪台机器都能原样运行。解决了「在我电脑好好的，到服务器就崩」的世纪难题。
- monitoring监控实时盯着系统的「健康仪表盘」：访问量、响应速度、错误率、服务器负载。出问题第一时间发现，而不是等用户来骂。
- alerting报警系统出异常时「自动通知值班人」（短信/电话/群消息）。半夜服务器挂了，报警把人叫起来救火，靠它兜底。
- load负载 / 并发量服务器当前「扛了多大的活」。负载太高会变慢甚至崩。知道负载，才能判断「要不要加机器、能扛多少用户」。
- CDNCDN（内容分发）把图片、视频等「就近存到离用户最近的节点」，加速加载。北京用户访问北京的节点、广州用户访问广州的，谁都快。
- crawler爬虫自动「逐页抓取网页内容」的程序，搜索引擎靠它收录全网，比价/数据采集也用它。它像不知疲倦的机器人在网上自动翻页、抄信息。
- HTTPSHTTPS / 证书给网站加把「安全锁」，让你和网站之间的数据传输被加密、不被偷看篡改。地址栏那个小锁头就是它，没有它浏览器会警告「不安全」。
- ICP 备案备案在中国大陆，网站要合法对外开放，需向监管部门「登记报备」拿到备案号。没备案的服务器在境内会被拦，是上线绕不开的一步。
- growth rate用户增长率用户数「涨得多快」。比如这月比上月多了 20%。它衡量产品「火不火、还在不在长」，是创业团队最关心的命脉数字之一。
- new users新增用户某段时间内「第一次来的人有多少」。新增看拉新能力，但光拉新不留人也白搭，得和留存一起看。
- DAU / MAU日活 / 月活（DAU/MAU）每天 / 每月「真正打开用的人数」。注册了不用不算数，活跃才是真价值。DAU/MAU 是衡量产品「有多少人真在用」的硬指标。
- retention留存率用户来了之后「还愿意再回来」的比例，比如「第 7 天还在用的占多少」。留存高说明产品真有用——拉来一百个走光九十九，等于白干。
- churn流失率用户「用着用着不来了」的比例，是留存的反面。流失高是危险信号，得赶紧查「是哪儿让人失望了」。
- conversion转化率用户「完成你希望的动作」的比例，比如「看了商品页的人里，多少真下单了」。转化是把流量变成价值的关键一环。
- CAC获客成本 CAC「拉来一个新用户平均花了多少钱」（广告、推广摊下来）。如果获客成本比用户带来的收益还高，那就是赔本赚吆喝。
- LTV用户生命周期价值 LTV「一个用户从头到尾总共能给你带来多少价值」。健康的生意要 LTV 大于获客成本——花 10 块拉来的人得赚回 10 块以上。
- tracking数据埋点在产品里「悄悄装上计数器」，记录用户点了什么、停留多久、从哪流失。有了这些数据，改进才有依据，不靠拍脑袋。
- funnel漏斗分析把「一步步流程」画成漏斗看每步漏掉多少人，比如「浏览→加购→下单→支付」。哪一层掉得最多，就重点优化哪儿。
- A/B testAB 测试同时上线两个版本（A 和 B），各给一半用户，看「哪个数据更好」再全量。用真实数据做决定，而不是靠争论谁的审美对。
- segmentation用户分群把用户「按特征分成几拨」（新/老、活跃/沉睡、付费/免费），针对性地运营。对不同的人说不同的话，比一刀切有效。
- north star北极星指标全团队「共同盯着的那一个最关键指标」，它指引方向、对齐目标。比如内容产品看「总阅读时长」。选对北极星，全员才不跑偏。
- ROIROI（投入产出比）「花出去的钱，赚回来多少」。ROI 大于 1 才划算。做任何投入（买量、做活动）前后都该算这笔账，别做亏本买卖。
- tech stack技术栈做一个项目「用到的一整套工具组合」（语言+框架+数据库等）。就像做菜的「全套锅具食材」。不懂没关系，可以直接问 AI「我要做 X，推荐一套适合新手的技术栈」。
- architecture架构项目「整体怎么搭、各部分怎么分工」的设计蓝图，相当于盖楼前的结构图。架构清晰，代码才不会越写越乱。可以让 AI「先帮我设计架构、画出模块划分，再动手写」。
- context上下文AI「当前记得住的信息范围」——你们这段对话里说过的话。AI 不是无限记忆，超出上下文它就开始忘。理解这点，是用好 AI 的前提。
- context compression上下文压缩对话太长 AI 会变笨、变忘。压缩 = 「把前面聊的重点浓缩成一小段，再继续」。实操：①让 AI「总结一下我们目前的进展和关键决定」，把总结存下来；②开新对话时先贴这段总结；③别在一个对话里东拉西扯，一个对话只干一件事。
- prompt engineering提示词工程「把话说清楚、让 AI 给出你要的结果」的技巧。核心是：讲清背景、给出例子、明确要什么格式。说得越具体，AI 答得越准——这正是「行话」整个站在教的事。
- iterative dev迭代开发别指望一句话让 AI 做出完美成品。正确姿势是「先做个能跑的小版本，再一点点加功能、改问题」。实操：把大需求拆成一步步，每步让 AI 只做一点、你验收没问题再进行下一步。
- feeding docs给 AI 喂文档AI 不懂你的项目细节或某个新工具时，「把相关文档/代码/规则直接贴给它看」，它就能照着办。实操：开工前先喂它「项目说明、目录结构、你的代码规范」，它后面就不会乱来。
- scope control让 AI 别乱改AI 有时会「顺手」改你没让它动的地方，越帮越乱。实操：明确圈定范围——「只改这个函数，其他一律别动」「保持现有风格，不要重构」。给它划好红线，它才不越界。
- project structure目录结构项目里「文件夹和文件怎么摆放」的组织方式。结构清晰，你和 AI 都能快速找到东西、不乱套。可以让 AI「按最佳实践帮我规划目录结构并解释每个文件夹干嘛的」。
- debug with ai报错排查代码报错别慌，AI 是你最好的排错搭子。实操：把「完整的报错信息 + 相关代码 + 你做了什么操作」一起贴给 AI，让它解释「错在哪、怎么改」。报错越完整，它越能一针见血。
- Git版本管理 / Git给代码「定期存档、可随时回退」的工具。改崩了能退回上一个好版本，是后悔药。实操：不懂命令没关系，让 AI「教我用 Git 把当前代码存一个档」，照着敲就行。
- requirement breakdown需求拆解给 AI一次让 AI 做太多它会做砸。实操：把「我要做个完整 App」拆成「①先做登录页 ②再做列表 ③再做详情」，一次只丢一个小任务给它。拆得越细，成功率越高。
- SDK / APISDK / 调用 API想用别人现成的能力（地图、支付、AI 接口），就「调用它们提供的工具包(SDK)或接口(API)」，不用自己造。实操：让 AI「帮我接入 XX 的 API，给出完整步骤和代码」。
- open source开源 / 开源协议很多优秀代码是「公开免费、可直接用」的（开源）。但要看「开源协议」——有的随便用，有的要求标注来源或不可商用。用前让 AI「解释下这个协议能不能商用」，免得踩法律坑。