Question 1

如何修复 AI-DLC 'log review' 错误："the reviewer appendix must contain exactly one Reviewer line matching the requested reviewer"？

Accepted Answer

这是 AI-DLC v2.11.0 中的一个已知 bug，已在 v2.11.1 中修复（通过 #2221）。在 2.11.0 中，`core/tools/aidlc-lib.ts` 里的 reviewer-authority 检查会统计每一个 `**Reviewer:**` 行，因此当审查文件以智能体的身份标记开头（例如 `**Reviewer:** aidlc-product-lead-agent`），再加上 verdict 块自身的 Reviewer 行时，就会被计为两行，从而拒绝该审查。修复方法：将 AI-DLC 升级到 v2.11.1 或更高版本（或更新您锁定的框架版本）。自 2.11.1 起，逐字重复的 Verdict、Reviewer 或 Iteration 行只计为一行，因此以身份标记开头的审查文件可以正常记录，其所有发现都会在 gate 处显示。而命名了不同智能体的第二个 Reviewer 行仍会被正确拒绝。如果停留在 2.11.0，临时解决方案是：在 dispatch brief 中指示执行审查的智能体从 `## Review` 开始审查文件，并且只包含一个 Reviewer 行，放在 verdict 块内部——而不是作为文件的第一行。注意：如果您在被拒绝后使用 `--retry-pending`，重试会有意从一个干净的槽位开始，不会携带被拒绝审查的发现，因此请手动在 gate 处呈现第一次审查的发现，以避免丢失 Major 发现。

Question 2

如何解决运行 aidlc engine state unit start 时出现的 "could not resolve the current routed unit (no diagnostic)" 错误？

Accepted Answer

此错误发生在 aidlc 2.10.0 中，因为 `unit start` 和 `unit complete` 内部的路由检查会生成一个子 `orchestrate next` 进程，并在约 30 秒后将其终止。如果 `next` 耗时更长（在大型工作区中很常见，例如 49,000+ 个文件时可能运行 20–125 秒），启动将被拒绝，并显示具有误导性的 "no diagnostic" 消息。

**修复方法：** 升级到 aidlc 2.11.0 或更高版本。PR #1369 将路由检查超时时间从约 30 秒提高到 5 分钟，因此缓慢的 `next`（20–125 秒）不再导致拒绝。这与解决 issue #1547 的修复相同。

**如果无法立即升级，可采用以下变通方法（Windows）：**
1. 关闭占用资源较多的进程（Chrome、其他 Claude Code 会话、Visual Studio）。
2. 临时移除前端的 `node_modules` 文件夹。
3. 通过连续运行 `aidlc engine orchestrate next` 2–3 次来预热文件缓存。
4. 通过 `Start-Process` 启动 `unit start`，然后在约 6 秒内每隔 300 毫秒将标记进程及其子 `next` 进程的 PriorityClass 设置为 High。

注意：这些变通方法仅在预热后的 `next` 能在约 30 秒内完成时才有帮助。如果在 2.11.0+ 上仍然出现拒绝，请测量一次普通的 `aidlc engine orchestrate next` 需要多长时间，并将其报告。

Question 3

为什么 Kiro CLI 子代理运行的模型与通过 /model 选择的模型不同？

Accepted Answer

Kiro CLI 子代理（被调度的 AI-DLC 代理，如 composer、developer、reviewers）不会继承通过 `/model` 或 `kiro-cli chat --model` 选择的会话模型。它们始终以保存的默认模型（`~/.kiro/settings/cli.json` 中的 `chat.defaultModel`）启动，因为 Kiro 子代理只继承 steering 文件、MCP 服务器、工作区访问权限、spec 状态和权限——而不继承模型。`/model` 切换只影响当前聊天，直到你将其保存。

修复方法：在 Kiro CLI 中运行 `/model set-current-as-default`，或在调度代理之前运行 `aidlc config models --session-model <model-id> --yes`，使 `chat.defaultModel` 与你预期的模型一致。这还可以防止当保存的默认模型变得不可用（"model is unavailable, retrying now"）时发生调度失败，而 conductor 却仍在继续工作的情况。

在 AI-DLC v2.11.1（PR #2405）中，文档、`aidlc config models --show` 和 `aidlc doctor` 已被更正为说明代理以 Kiro 设置中保存的模型启动，而不再是声称它们继承会话模型。

Question 4

当插件构建挂起15分钟时，如何修复"could not acquire plugin build output lock"错误？

Accepted Answer

挂起是权限问题，而不是锁竞争。共享锁文件夹 `/tmp/aidlc-plugin-build-locks` 由最先执行构建的用户（例如 CI 中的 root）以 0700 模式创建，因此其他任何用户都会得到 `EACCES` 错误，该错误每 25 毫秒被静默重试一次，直到 900000 毫秒（15 分钟）超时。解决方法 —— 在运行构建之前，为每个用户提供其自己的临时目录： ```sh mkdir -p "$HOME/.tmp" export TMPDIR="$HOME/.tmp" TMP="$HOME/.tmp" TEMP="$HOME/.tmp" bun /aidlc-plugin-build.ts ``` 在 CI 中，如果前面的步骤以 root 身份运行，而后面的步骤以非特权用户身份运行，请在非特权步骤中将 `TMPDIR`/`TMP`/`TEMP` 设置为该作业的 scratch 目录内的某个文件夹。或者，作为该文件夹的所有者，可以通过设置 sticky bit 使共享锁目录对所有人可访问：`chmod 1777 /tmp/aidlc-plugin-build-locks`。使用 `ls -ld /tmp/aidlc-plugin-build-locks` 进行验证 —— 如果显示的模式为 `drwx------` 且所有者是其他用户，那么这就是问题的原因。

Question 5

如何修复出现 "Refusing to complete feasibility" / SUMMARY_QUESTIONS_MISSING 错误的 t242 测试失败问题?

Accepted Answer

测试 `tests/unit/t242-state-transition-guard.test.ts` 失败，原因是其裸 fixture 中没有 stage-questions 文件，因此引擎的 `gate-start` 以 `"reason_codes":["SUMMARY_QUESTIONS_MISSING"]` 拒绝——该测试相对于后来添加的前置条件已经过时，而不是逻辑出了问题。有两种修复方法：

1. **推荐：** 在测试派生的环境中设置 `AIDLC_SKIP_SUMMARY_CONFIRMATION_GUARD=1`。这与 `tests/unit/t-guard-refusal-actionable.test.ts` 中的先例一致，并能让测试专注于 gate 词。验证方式：
```bash
AIDLC_SKIP_SUMMARY_CONFIRMATION_GUARD=1 bun test tests/unit/t242-state-transition-guard.test.ts
# → 56 pass, 0 fail
```

2. **备选：** 在 fixture 中预置一个 `feasibility-questions.md` 文件，以便走真实的 guard 路径——更忠实，但会让测试与 summary-confirmation 流程耦合。

注意：此失败并非由泄漏的 `CLAUDE_CODE_SESSION_ID` 引起（那是单独的 t265 问题）；取消设置该变量并不能修复此问题。

aidlc-workflows

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐