Core Judgment
不是把 Prompt 写得更长，而是把 AI 需要看见的信息环境组织清楚。
本页提供模型、清单、模板和流程，用于组织复杂任务所需的信息环境。
BRACEChecklistContext Pack
Loading...
Loading...
Context Engineering 关注系统提示、任务背景、输入材料、历史信息、工具边界和验收标准的组合方式。它让复杂任务不只依赖一句指令，而是拥有可控、可复用、可迭代的协作环境。
Core Judgment
本页提供模型、清单、模板和流程，用于组织复杂任务所需的信息环境。
Core Ideas
Context Engineering 的重点不是让提示词更复杂，而是让 AI 拥有完成任务所需的背景、材料、边界和验收方式。
Prompt 告诉 AI 要做什么；Context 决定 AI 在什么背景、材料、限制和标准下完成任务。
信息太少会空泛，信息太多会混乱。关键不是全部塞进去，而是选择、排序、压缩和更新。
好的 Context 不只提升一次输出，还能沉淀成模板、流程和检查点，让后续任务更稳定。
Reusable Templates
使用时将【】中的占位内容替换为当前任务材料，并要求 AI 先复述任务理解。
你是「100天 AI Product Builder 计划」的长期协作助手。
项目目标：【长期目标】
我的背景：【个人背景/当前阶段】
语言风格：【真实、清晰、克制、中文为主】
长期规则：【隐私边界/不要编造/缺信息先提问】
当我提出具体任务时，请结合以上背景执行，并先复述你的理解。请作为内容编辑，帮助我完成【写作任务】。
主题：【主题】
读者：【目标读者】
素材：【我的笔记/经历/摘录】
表达要求：【保留真实思考，避免 AI 味】
输出格式：【文章/卡片/复盘/小红书草稿】
请先给出结构大纲，确认后再写正文。请作为 AI 产品分析师，拆解【产品名称】。
分析目的：【为什么拆这个产品】
输入材料：【官网/体验记录/公开资料】
关注维度：【用户、场景、痛点、AI 介入点、价值、风险】
限制条件：【区分事实和判断，不夸大未知信息】
请先输出拆解大纲和需要补充的信息。请作为我的 Codex 协作工程师处理【修改目标】。
项目背景：【Next.js 个人网站/当前页面结构】
相关文件：【文件路径】
修改范围：【只改哪些模块】
限制条件：【不重建项目、不加复杂依赖、不删除重要内容】
检查点：【先读结构并给方案，确认后再改，完成后说明文件变化和验证结果】请作为 AI 前沿周报编辑，整理【时间范围】内的 AI 动态。
关注领域：【模型/产品/研究/应用】
输入材料：【新闻链接/公告/论文】
输出结构：【事实、解释、对 100 天计划的影响】
限制条件：【不编造来源，事实和预测分开】
请先列出事件清单，再写周报正文。请作为反方顾问，挑战我的观点：【观点】。
我的理由：【已有判断】
允许挑战范围：【产品/技术/用户/执行风险】
输出格式：【原观点复述、反方论点、风险、改进建议】
限制条件：【不攻击个人，保留原观点合理部分】
请先确认你理解的观点，再提出反方分析。请作为信息架构师，整理我的个人网站内容。
网站主题：【100天 AI Product Builder 计划】
主入口：【分日复盘、方法论、学习画册、Demo Lab】
内容材料：【待归类内容】
风格约束：【高级、简洁、克制、中文为主】
限制条件：【不重建结构，不硬塞全文，不让页面像论文】
请先判断内容归属，再给执行计划，等我确认后再修改代码。Prompt vs Context
Prompt Engineering 和 Context Engineering 不是替代关系。前者让任务表达更清楚，后者让复杂协作更稳定。
BRACE Model
BRACE 把 Context 拆成五层：长期背景、角色、本次任务、限制条件和验收标准。复杂任务开始前，先检查这五层是否完整。
Base
项目目标、长期规则、个人风格、隐私边界和持续积累的资料。
Role
AI 当前扮演什么角色，需要承担什么职责，语气和能力边界是什么。
Assignment
这一次要完成什么、输入材料是什么、希望输出成什么形态。
Constraint
不能做什么、必须遵守什么、是否允许调用工具、是否能修改代码。
Evaluation
怎样判断结果可用，是否需要先提问、先出方案、分阶段确认。
Checklist
这组问题适合放在写作、产品拆解、Codex 修改网站、周报整理和 Demo 规划之前。
01我是谁，以及当前项目是什么？
02这次任务的目标是否能用一句话说清？
03目标读者、用户或使用场景是什么？
04已有输入材料、链接、代码或草稿在哪里？
05希望输出为文章、表格、代码、清单还是页面方案？
06语气、风格、长度和中文表达要求是什么？
07有哪些不要做的事或不能越过的边界？
08AI 是否可以直接执行，还是必须先等待确认？
09复杂任务是否设置了阶段性检查点？
10最终结果用什么标准验收？
Context Pack Library
每个 Context Pack 对应一种任务场景，并列出组织上下文时需要优先提供的字段。
为 100 天计划建立长期背景、语言风格、隐私边界和协作规则。
保留真实思考、个人语气和引用来源，避免只得到模板化总结。
围绕用户、场景、痛点、AI 介入点、商业价值和项目启发展开。
先读结构、先出方案、确认后执行，保持现有架构稳定，不引入复杂依赖。
明确时间范围、来源要求和事实/解释/建议的边界，避免信息堆砌。
让 AI 先复述原观点，再提出反方证据、风险和更稳健的替代方案。
把内容清单归入分日复盘、方法论、学习画册和 Demo Lab，避免页面失焦。
Workflow
先判断任务，再选择模板；先校准理解，再进入执行；最后把有效上下文沉淀下来。
判断任务类型
选择合适的 Context Pack
补充当前任务材料
设置输出格式
写清限制条件
设置检查点
让 AI 复述理解
确认后执行
根据结果迭代 Context
沉淀成可复用模板
Task Matrix
同一套提示词不能解决所有问题。先判断任务类型，再决定最重要的上下文是什么。
关键 Context：作者背景、受众、素材、观点、风格。
缺失后果：文章空泛，失去个人语气。
关键 Context：产品资料、用户场景、AI 介入点、价值和风险。
缺失后果：报告像功能复述，缺少判断。
关键 Context：项目结构、技术栈、相关文件、修改边界。
缺失后果：容易破坏现有架构或引入不必要依赖。
关键 Context：时间范围、可靠来源、事实/解释/建议区分。
缺失后果：信息混乱，结论和事实混在一起。
关键 Context：网站目标、四个入口、内容清单、风格约束。
缺失后果：建议空泛，无法落到真实页面。
Common Mistakes
Context 的问题往往不是不会写提示词，而是没有说明边界、材料、检查点和验收方式。
补齐身份、背景、材料、输出格式和验收标准。
先筛选与任务有关的信息，把参考材料按重要性排序。
在 Constraint 层写清不要编造、不要重写项目、不要引入复杂依赖等边界。
设置先大纲、再展开、再检查的阶段性确认点。
在 Evaluation 层说明什么叫可用、如何检查、失败时如何迭代。
Applications
同一套上下文组织方法可以用于复盘、方法沉淀、知识整理和 Demo 构建。
用 AI 写作 Pack 保留当天真实思考，再把复盘压缩成公开可读的记录。
把 BRACE、Checklist、流程和模板库沉淀为长期可复用的能力资产。
把 BRACE 模型、Context Checklist 和任务差异表转化成可视化知识卡片。
把 Vibe Coding Pack 变成 Codex 协作规范，服务后续 Demo 构建。