问题与任务记录
Issue
学到 认得 就够：听到能明白
你可能会说
“我发现课题网站有一个筛选问题，怎样把现象、复现步骤和处理进度记在一起？”
Issue是围绕一个问题或任务保存讨论、状态、标签和责任信息的记录。在GitHub里，它常用于报告错误、提出需求和跟踪工作，并不限于程序崩溃这类技术问题。
使用 AI
科研里的例子
记录手机页面表格溢出：给出屏幕宽度、页面位置、预期阅读效果和复现步骤。
好的Issue把可复现的现象、预期行为、材料和验收条件写清楚。它可以与PR或项目管理视图关联，但“关闭”是平台状态，是否实际解决仍要看结果。Issue也不能自动代替研究证据台账。
动手试一次
把一个模糊需求写成现象、预期、范围、验收四段草稿，先不对外提交。
在你的学科里，直接拿去用
查错并交付能核验的修复
请定位问题并给最小修复。 代码与环境：[粘贴] 输入样例：[不含私密信息的小样本] 实际错误或输出：[粘贴] 我期望：[填写] 先区分已观察事实与可能原因，优先用最小样例验证。解释根因，给最小差异和有意义的检查。没有实际运行权限时明确标为未运行建议，不把推测写成测试通过。若修改会影响研究规则或结果，指出具体影响，不顺手重构无关部分。方括号里的内容换成你自己的。来自知识增量《科研中英表达与 Prompt 指南》PG09
判断
亲手检查一次
按验收条件重新观察问题；不能只凭关闭标签认定完成。
它做不到的
Issue是任务讨论，PR是拟合入的改动。两者关联后仍各有状态。
增量，由你来写
读完这张，你的理解变了什么？
留言功能会在后面的版本开放。现在可以先在 X 上 @knowledgedelta 告诉我。