先明确任务与结果
先确认使用的是新的合并GitHub应用，再用不含私人资料的小仓库和已知答案检查通知、任务、PR与测试。旧应用的迁移日期与一次任务的成功是不同问题；出现PR也不等于测试、合并或部署已经完成。
先识别入口，别在旧应用里重复排查
GitHub10月23日公告说明：原GitHub notifications应用更新为合并入口；既有通知用户应更新应用，原通知能力保留。另一个旧GitHub应用将标为GitHub (deprecated)，计划11月16日退役；公告要求改用合并应用。
在合并应用中，按官方提示连接自己的GitHub账户并选择仓库。能否安装、连接和执行仍取决于自己的组织与实际可用范围，不能因为看到公告就假定所有人已开通。本篇不承诺订阅权益或额度。
| 记录项 | 要看到的证据 | 不能用什么代替 |
|---|---|---|
| 应用身份 | 当前安装的是哪个GitHub应用 | 只看相似图标 |
| 仓库身份 | 明确的owner/repository与分支 | 频道里口头叫作“主仓库” |
| 任务对象 | 具体issue链接与验收条件 | 只有一条模糊提醒 |
| 后续产物 | 对应任务的PR和检查结果 | 仅有聊天回复或完成状态 |
给试用准备一个能够独立判断的错误
下面的代码和预期结果都是编辑设计的练习，不是真实事故或某个模型的输出。函数的输入契约限定为数组，任务是返回附件数量，不负责解析文件或判断附件内容。这样可以把身份、入口和代码结果分别检查。
错误在循环边界：它跳过了最后一个元素。空数组恰好返回正确的0，因此只测空数组会掩盖问题。单元素与三元素样本分别把遗漏显露出来。
function countAttachments(items) {
let count = 0;
for (let i = 0; i < items.length - 1; i++) count++;
return count;
}
// Editorial reference cases:
// [] -> 0
// ['draft.pdf'] -> 1
// ['a.png', 'b.png', 'brief.pdf'] -> 3| 输入 | 正确数量 | 原错误代码结果 | 这一行检查什么 |
|---|---|---|---|
| [] | 0 | 0 | 空输入本身不能暴露遗漏 |
| ['draft.pdf'] | 1 | 0 | 单元素边界 |
| ['a.png','b.png','brief.pdf'] | 3 | 2 | 最后一个元素被跳过 |
把通知变成一个明确的任务对象
在你有权使用的练习仓库记录这个issue，把函数位置、三个输入及预期结果附上。等通知进入正确的Teams位置后，先核对issue和仓库，再通过新应用的入口提交明确任务。这里描述的是读者的试用步骤，本文没有在Teams执行它们。
下面的提示词故意限制改动范围。它不要求工具把通知文本当成可信需求全集，而是把issue与固定参考结果作为验收依据。缺少issue、代码或仓库身份时先补材料，不让智能体自行猜目标。
Investigate the linked practice issue in the selected repository.
The input contract of countAttachments is an array. Fix only the off-by-one counting error.
Reference results:
[] => 0
['draft.pdf'] => 1
['a.png', 'b.png', 'brief.pdf'] => 3
Add or update checks for these three cases. Explain which boundary was wrong.
Create a pull request for review. Do not merge or deploy.
If the issue, file or repository cannot be identified, stop and state the missing item.打开PR以后，沿着三条线检查
先检查身份链：通知、issue、仓库、分支和PR是否对应同一任务。再检查改动链：是否只修正计数边界，没有顺手改动文件解析、上传或其他函数。最后检查结果链：三个样本是否独立执行，测试失败和未运行的项目是否如实记录。
对这里的数组契约，直接返回items.length是一种简单参考解法，也可以修正循环边界。判断重点是结果与范围，不是强制某种代码风格。修改输入契约为“只计PDF”等其他任务，不能被算作修复原问题。
PR存在，但修复仍不合格
把循环末尾补上后，只展示空数组通过；另外悄悄改成忽略PNG附件。
检查全部三个参考结果，并核对函数仍统计输入数组的所有元素。
迁移成功与代码修复成功分别登记
迁移前保留原通知订阅和目标仓库的记录。在新入口确认同一个受控测试issue确实到达、可识别且没有重复触发后，再按自己的管理流程处理旧入口。本文不修改组织安装或权限设置。
多仓库情况下，先阅读Copilot排查与选择仓库的流程；如果处理的是代码扫描告警而不是本例issue，参考agentic autofix的PR审查边界。不要把不同入口的状态与本例试用结果混成一个“全部支持”。
一次有结论的试用记录
- 应用与仓库身份明确，使用日期已记录。
- 测试issue与通知能互相定位。
- PR对应同一任务，改动范围可审查。
- 三项参考输入结果都已检查，未运行项单列。
- 合并、部署和线上验收保持独立后续步骤。
这份练习刻意没有验证哪些能力
这不是性能对比，也没有调用模型、安装Teams应用、生成真实issue或PR。文中的错误代码与答案用于建立人工作答基线；它们不能证明某个账户已获得功能，或某个模型一定会修对。
若当前租户或仓库无法使用该入口，先记录实际提示和已核实的条件，保留现有可靠流程，不通过扩大权限或自动合并来“证明”试用成功。
常见问题
已经装了GitHub notifications还要重新装吗？
公告对既有通知用户的要求是更新到最新合并应用。先核对具体应用身份；不要把它与计划退役的旧GitHub应用混为一谈。
我可以用正式生产故障直接试吗？
这份练习建议先用小型已知样本建立完整验收链。正式问题需要对应的授权、材料和审查流程，不能由一个演示案例替代。
三个测试通过是否就能自动上线？
不能。它们只验证此处的数组计数契约；完整项目检查、人工审查、合并和部署仍是另外的步骤。
