https://cuespec.ai/zh/blog/CueSpec 团队的重构请求、任务交接卡与输入方式评估表，可直接用于自己的工作。zh-CNhttps://cuespec.ai/zh/blog/ai-coding-task-handoff-card/https://cuespec.ai/zh/blog/ai-coding-task-handoff-card/用交接卡保存任务、材料、已定决策和下一步，附空白模板、两份完整虚构案例及恢复请求。https://cuespec.ai/zh/blog/hybrid-voice-and-code-refactor-brief/https://cuespec.ai/zh/blog/hybrid-voice-and-code-refactor-brief/用可复制的重构任务说明、精确标识表和虚构费用规则案例，明确允许修改范围、行为不变量与复核要求。https://cuespec.ai/zh/blog/compare-typing-and-dictation-workflow/https://cuespec.ai/zh/blog/compare-typing-and-dictation-workflow/按同样任务和可发送终点比较打字、口述与混合输入，附条件记录、计时边界、改错分类和空白决策表。https://cuespec.ai/zh/blog/ui-feedback-with-screenshot-and-voice/https://cuespec.ai/zh/blog/ui-feedback-with-screenshot-and-voice/用编号区域、可复制模板和三份完整示例，把截图与口述反馈变成可以检查的 UI 修改请求。https://cuespec.ai/zh/blog/review-ai-code-change-against-request/https://cuespec.ai/zh/blog/review-ai-code-change-against-request/把要求、代码改动和实际证据逐项对应，用虚构 Python 补丁、示例断言和复核表判断下一步。https://cuespec.ai/zh/blog/understand-codebase-before-agent-changes/https://cuespec.ai/zh/blog/understand-codebase-before-agent-changes/沿陌生仓库的一条执行路径，记录文件证据与未知项，再写出范围明确的后续改动请求。https://cuespec.ai/zh/blog/local-tests-pass-ci-fails-agent-brief/https://cuespec.ai/zh/blog/local-tests-pass-ci-fails-agent-brief/对照同一修订的本地与CI环境，区分样例路径和缓存假设，再选择一项能区分原因的检查。https://cuespec.ai/zh/blog/choose-ai-dictation-input-route/https://cuespec.ai/zh/blog/choose-ai-dictation-input-route/按文字去向、复查和处理阶段选择Mac听写路径，包含四工具的条件比较、离线英文整理虚构案例及可复制路径卡。https://cuespec.ai/zh/blog/conflicting-feedback-to-agent-brief/https://cuespec.ai/zh/blog/conflicting-feedback-to-agent-brief/分别保留反馈来源、观察与建议，记录已定约束和未决分歧，再整理成一份范围明确的 Agent 任务说明。https://cuespec.ai/zh/blog/loading-cancellation-and-late-results-ui/https://cuespec.ai/zh/blog/loading-cancellation-and-late-results-ui/用六个事件的时间线，明确加载、取消与迟到响应的归属，并为界面修改写出可检查的行为要求。https://cuespec.ai/zh/blog/dependency-upgrade-compatibility-brief/https://cuespec.ai/zh/blog/dependency-upgrade-compatibility-brief/梳理直接与间接依赖变化，保留调用方契约，并明确兼容性检查和回退条件。https://cuespec.ai/zh/blog/specify-who-can-read-and-change-a-record/https://cuespec.ai/zh/blog/specify-who-can-read-and-change-a-record/用角色、记录所有权与动作矩阵明确读取和修改边界，包含拒绝案例、成员资格撤回流程和可复制授权设计请求。https://cuespec.ai/zh/blog/partly-successful-batch-before-repeating/https://cuespec.ai/zh/blog/partly-successful-batch-before-repeating/通过五项虚构记录，区分成功、跳过、失败和未知结果，并明确修正与核实的后续步骤。https://cuespec.ai/zh/blog/define-unique-order-before-pagination/https://cuespec.ai/zh/blog/define-unique-order-before-pagination/通过八条虚构记录、两份完整结果及分页变化示例，明确唯一排序与结果保留规则。https://cuespec.ai/zh/blog/units-and-rounding-in-coding-brief/https://cuespec.ai/zh/blog/units-and-rounding-in-coding-brief/通过九组长度示例，分别定义输入单位、精确保存、计算精度、显示舍入与编辑行为。https://cuespec.ai/zh/blog/turn-file-upload-rules-into-observable-outcomes/https://cuespec.ai/zh/blog/turn-file-upload-rules-into-observable-outcomes/用九份虚构文件描述和状态表明确接收、检查、可访问、重试、过期与清理边界。https://cuespec.ai/zh/blog/specify-an-offline-edit-conflict-before-choosing-a-merge/https://cuespec.ai/zh/blog/specify-an-offline-edit-conflict-before-choosing-a-merge/用双设备的不同字段、同字段和保存响应丢失历史，明确版本条件、冲突决定与保留本地草稿的规则。https://cuespec.ai/zh/blog/keyboard-shortcuts-focus-and-composition/https://cuespec.ai/zh/blog/keyboard-shortcuts-focus-and-composition/用三乘三焦点／组合输入矩阵、十二步按键历史和完整请求，界定预览快捷键的文本输入边界。https://cuespec.ai/zh/blog/modal-opening-to-return-focus-flow/https://cuespec.ai/zh/blog/modal-opening-to-return-focus-flow/用完整对象地图、双向焦点移动表和触发控件消失历史，说明只读弹窗从打开到焦点返回的流程。https://cuespec.ai/zh/blog/literal-text-or-markup-agent-brief/https://cuespec.ai/zh/blog/literal-text-or-markup-agent-brief/用无害字符串矩阵、完整JSON与DOM渲染示例，区分字面文本显示和待定格式化方案。https://cuespec.ai/zh/blog/background-job-status-and-result-contract/https://cuespec.ai/zh/blog/background-job-status-and-result-contract/用一个完整的三阶段作业案例，说清进度总量变化、私有中间产物、取消竞争与结果获取。https://cuespec.ai/zh/blog/incoming-events-version-and-reconciliation/https://cuespec.ai/zh/blog/incoming-events-version-and-reconciliation/用一份完整的虚构接收历史，处理重复投递、过时快照、事件 ID 冲突和明确的对账流程。https://cuespec.ai/zh/blog/finite-retry-budget-for-rate-limited-reads/https://cuespec.ai/zh/blog/finite-retry-budget-for-rate-limited-reads/用秒数与 HTTP 日期两种 Retry-After 日程，说清请求耗时、等待时间、尝试次数上限与明确的停止状态。https://cuespec.ai/zh/blog/stored-field-migration-old-new-readers/https://cuespec.ai/zh/blog/stored-field-migration-old-new-readers/请智能体重命名一个存储字段之前，先说明哪些读取方和写入方还可能使用旧名称。然后定义现有记录如何迁移、冲突值如何处理，以及从哪个阶段开始，回到旧版应用就不再只是一次代码回退。https://cuespec.ai/zh/blog/redirects-missing-routes-allowed-methods/https://cuespec.ai/zh/blog/redirects-missing-routes-allowed-methods/请智能体“修好旧 URL”之前，先列出这些 URL 会收到哪些请求。迁移后的阅读页面、POST 端点和未知路径，需要不同的结果。为每个请求写明状态码、适用时的目标地址，以及方法、请求体和查询参数的处理规则。https://cuespec.ai/zh/blog/unicode-search-matching-before-fuzziness/https://cuespec.ai/zh/blog/unicode-search-matching-before-fuzziness/请智能体让搜索“更宽容”之前，先决定哪些差异应该被视为相等。两个标签看起来可能相同，却使用不同的 Unicode 序列。另一些标签则在大小写、重音或字符宽度上不同。把这些差异都混成一个问题，会让搜索需求难以复核。https://cuespec.ai/zh/blog/keep-long-spoken-coding-request-recoverable/https://cuespec.ai/zh/blog/keep-long-spoken-coding-request-recoverable/把口述请求中已核对的部分，分别保留为文字笔记，再组装成要发送的消息。将明确的修正，记在它所替换的早先条款旁。如果某部分没有留下措辞，就保留可见缺口，请对方给出新的决定，而不要生成一份流畅却凭空补出的请求。https://cuespec.ai/zh/blog/switch-technical-task-to-voice-continuity/https://cuespec.ai/zh/blog/switch-technical-task-to-voice-continuity/处理技术任务时，如果想改用口述而非打字，先确定你希望答案从哪里来。你可以用语音为现有任务准备文字，也可以进入接收语音并作出回应的对话式语音通道。这两种选择看起来可能相似，但向你展示的信息可能不同。https://cuespec.ai/zh/blog/minimal-useful-debugging-context/https://cuespec.ai/zh/blog/minimal-useful-debugging-context/给调试智能体的材料，应足以区分下一步几个合理的解释：出错输入、预期行为及其依据、相关环境，以及把输入与故障连接起来的代码或日志。根据材料能回答的问题，选择是否补充。没有固定的理想材料包大小，上下文更短也不自动意味着更好。https://cuespec.ai/zh/blog/failing-test-to-bounded-agent-request/https://cuespec.ai/zh/blog/failing-test-to-bounded-agent-request/提供精确输入、断言、相关实现，以及证明预期结果正确的需求依据，失败测试就能为编程智能体提供有用的起点。在修改实现或断言之前，先让智能体检查：究竟是哪一方与需求不符。https://cuespec.ai/zh/blog/feature-need-vs-implementation-plan/https://cuespec.ai/zh/blog/feature-need-vs-implementation-plan/先说明用户想要的结果及其验收条件，再指定技术设计。把实现想法放在单独一节，让智能体可以调查它们，而不会把猜测误当成需求。https://cuespec.ai/zh/blog/parallel-agent-deliverables-and-dependencies/https://cuespec.ai/zh/blog/parallel-agent-deliverables-and-dependencies/围绕能够独立完成和检查的产物拆分并行工作。为每项任务指定必需的输入、由其负责的输出，以及下游工作可以开始的具体条件。这样，即使用普通笔记协调，而不使用智能体调度器，工作依赖图也能发挥作用。https://cuespec.ai/zh/blog/parallel-agent-file-ownership-and-integration/https://cuespec.ai/zh/blog/parallel-agent-file-ownership-and-integration/让一个角色对组合结果负责，再依据已知基线和预期行为整合每份交付物。两个分支各自都可能通过局部检查，却在某项共享设置上互相矛盾。真正需要回答的是：组合后的代码与配置是否实现了同一项功能。https://cuespec.ai/zh/blog/worktree-isolation-vs-conversation-context/https://cuespec.ai/zh/blog/worktree-isolation-vs-conversation-context/要求智能体编辑代码前，先检查两种对应关系：它可以修改哪个工作树，以及它的对话正在遵循哪一项任务指令。单独的目录有助于组织代码工作，却不能说明智能体记得什么，也不能说明它会将哪条指令视为当前指令。https://cuespec.ai/zh/blog/retry-same-action-or-new-one/https://cuespec.ai/zh/blog/retry-same-action-or-new-one/应用没有响应时，“再试一次”可能有两种含义：找回你已经发出的请求的结果，或者再要一个结果。在要求编码 agent 添加重试之前，先告诉它你想要哪一种。https://cuespec.ai/zh/blog/specify-what-undo-restores/https://cuespec.ai/zh/blog/specify-what-undo-restores/定义 Undo 操作时，要说明它逆转哪次操作、允许改变哪些字段，以及必须保留哪些后续工作。然后描述恢复与另一项操作冲突、恢复失败或结果未知时，应当怎么办。https://cuespec.ai/zh/blog/accessible-form-repair-agent-brief/https://cuespec.ai/zh/blog/accessible-form-repair-agent-brief/为表单修复任务明确三个具体结果：用户能识别每个字段、用键盘完成任务，并知道出错后如何恢复。提供表单状态与所需检查，而不是不描述交互，只让 Agent“把它做得无障碍”。https://cuespec.ai/zh/blog/csv-import-contract-and-edge-cases/https://cuespec.ai/zh/blog/csv-import-contract-and-edge-cases/向 Agent 说明 CSV 导入任务时，应分别定义可接受的文件格式与数据规则，再提供小文件及其确切的接受或拒绝结果。“读取这份 CSV”会把编码、重复项、空值和失败处理留给猜测。https://cuespec.ai/zh/blog/api-change-contract-agent-brief/https://cuespec.ai/zh/blog/api-change-contract-agent-brief/API 改动任务说明应展示既有调用方收到什么、新调用方可以请求什么、错误如何处理，以及哪些兼容性说法仍需检查。“增加一个摘要字段”并不够：字段不存在、字段值为 null，以及必填字符串，是三份不同的契约。