refactor(pipeline): 抽取提示词模板为独立helper并添加最小切入原则

.gitignore

@@ -17,3 +17,6 @@ bin/
 
 # Runtime artifacts
 .code-bee/
+
+# Build output
+worker

internal/pipeline/prompts.go

@@ -97,13 +97,43 @@ func buildCodingPrompt(
 	maxRounds int,
 ) string {
 	return fmt.Sprintf(
-		`你是蜂巢编码智能体 @%s。
+		buildCodingPromptTemplate(),
+		issueResult.Agent,
+		resultFilePath,
+		workerID,
+		cfg.Repo,
+		cfg.IssueNumber,
+		issueURL,
+		platformName,
+		round,
+		maxRounds,
+		platformGuide,
+		issueResult.Summary,
+		issueResult.Acceptance,
+		reviewerFeedback,
+	)
+}
+
+// buildCodingPromptTemplate 返回编码阶段长提示词模板。
+//
+// 设计说明:
+// - 将长模板抽出为独立 helper，避免构造函数承担过多行数，同时让 lint 更容易通过
+func buildCodingPromptTemplate() string {
+	return `你是蜂巢编码智能体 @%s。
 
 你的职责：
 1. 自己查看 Issue 并完成实现、自验、必要的 PR 操作
 2. 把本轮结果写入指定 JSON 文件
 3. 不要直接提交 Issue 评论，Issue 评论由专门的 Issue 提交智能体完成
 
+最小切入原则（修正/开发/推进均适用，违反即停手）：
+- 修正：只改导致问题的根因行。不顺手重构周边代码，不修"附近"的其它问题，不做纯格式化，不改未在反馈中提到的文件
+- 开发：只实现 Issue 验收标准要求的功能。不写"以防万一"的抽象，不加未要求的配置项或扩展点，不引入标准库/已有依赖能搞定的外部依赖
+- 推进：每轮只做一件聚焦的事。不把多个不相关改动打包进同一轮；下一轮基于本轮证据再决定是否扩大范围
+
+判断标准：你能为每一行改动找到和"当前 Issue 验收标准"或"本轮 reviewer 反馈"的直接关联吗？找不到 → 撤回该行。
+发现自己处于 Kitchen Sink（修水龙头拆厨房）、Runaway Refactor（连锁修改）、Over Abstraction（为以后而抽象）任一状态 → 立即停手，回退到本轮最小改动再提交。
+
 你必须把结果写入以下文件：
 - 结果文件: %s
 
@@ -143,21 +173,8 @@ Issue 摘要:
 4. 如果还需要继续开发或补证据，写入 "status": "IN_PROGRESS"
 5. 如果因权限、环境、外部依赖等无法继续，写入 "status": "BLOCKED"
 6. 结果文件必须可被机器稳定解析，不能写 Markdown，不能混入解释
-7. 不要直接提交 Issue 评论`,
-		issueResult.Agent,
-		resultFilePath,
-		workerID,
-		cfg.Repo,
-		cfg.IssueNumber,
-		issueURL,
-		platformName,
-		round,
-		maxRounds,
-		platformGuide,
-		issueResult.Summary,
-		issueResult.Acceptance,
-		reviewerFeedback,
-	)
+7. 不要直接提交 Issue 评论
+8. 每一行改动必须能说出与 Issue 验收标准或本轮 reviewer 反馈的直接关联；做不到的撤回该行，不要硬提交`
 }
 
 // buildReviewPrompt 构造审查阶段提示词。