feat(core): 批2多流程模板声明层+投标技术方案技能——ability.py FlowTemplate数据类(key/name/detect_criteria/stages)+PipelineAbility.flow_templates+get_flow_stages(flow_key=)/get_flow_templates/get_flow_template/flow_template_to_dict;技能:新建bid-tech-proposal(纯技术方案流程规范,六类评估项+角色分工+装配链铁律注释)/bid-workflow补多流程模板段/bid-qc补tech_items;角色技能:tender_analyst(analysis_dim=tech分支+3工具)/pm(tech_template任务+bid_tech_capability声明)/qc(tech_items审核)/writer+reviewer(对标需求书规则);project-directory-spec去SDLC化(global兜底+bidding/opportunity产线版)
This commit is contained in:
parent
10781e7a65
commit
474d3ea247
@ -22,6 +22,7 @@ from .ability import (
|
||||
PipelineAbility,
|
||||
RoleSpec,
|
||||
FlowStage,
|
||||
FlowTemplate,
|
||||
register_ability,
|
||||
get_ability,
|
||||
list_abilities,
|
||||
@ -32,6 +33,9 @@ from .ability import (
|
||||
get_next_role,
|
||||
list_roles,
|
||||
get_flow_stages,
|
||||
get_flow_templates,
|
||||
get_flow_template,
|
||||
flow_template_to_dict,
|
||||
flow_stage_to_dict,
|
||||
)
|
||||
from .slash import (
|
||||
|
||||
@ -64,6 +64,25 @@ class FlowStage:
|
||||
deps: List[str] = field(default_factory=list)
|
||||
|
||||
|
||||
@dataclass
|
||||
class FlowTemplate:
|
||||
"""产线的一条预制流程模板（多流程机制，2026-09-14 批2）。
|
||||
|
||||
一个产线可声明多条流程（如投标产线：标准投标流程 + 纯技术方案流程）。
|
||||
项目导入文件后由 LLM 按 detect_criteria 自动判流（语义判断归 LLM，
|
||||
判流结果进 flow_plan_confirm 待办由用户确认——错判由确认门兜住）。
|
||||
|
||||
detect_criteria：给判流 LLM 的分类依据（什么样的输入文件走这条流程），
|
||||
写清文件类型特征与业务场景，禁止只写关键词列表。
|
||||
stages：该流程的阶段链（FlowStage 列表，裁剪声明语义同单流程）。
|
||||
"""
|
||||
key: str # "bid_tech_proposal"
|
||||
name: str = "" # 展示名「纯技术方案流程」
|
||||
description: str = "" # 流程用途（展示给用户）
|
||||
detect_criteria: str = "" # 判流依据（LLM 分类用）
|
||||
stages: List[FlowStage] = field(default_factory=list)
|
||||
|
||||
|
||||
@dataclass
|
||||
class PipelineAbility:
|
||||
"""产线能力包：一个产线 = 一组工具 + 一段 prompt + 一组 handler + 一组角色。
|
||||
@ -81,6 +100,7 @@ class PipelineAbility:
|
||||
roles: List[RoleSpec] = field(default_factory=list) # 产线角色集
|
||||
menus: List[Dict] = field(default_factory=list) # 产线功能菜单（AgentIO 上方）[{"label","icon","url","type"}]
|
||||
flow_stages: List[FlowStage] = field(default_factory=list) # 预制流程阶段（空 = 该产线未声明可裁剪流程）
|
||||
flow_templates: List[FlowTemplate] = field(default_factory=list) # 多流程模板（≥2 条时文件导入触发 LLM 自动判流；空 = 单流程，用 flow_stages）
|
||||
|
||||
|
||||
# ── 全局注册表 ──
|
||||
@ -163,12 +183,47 @@ def get_ability_menus(pipeline_id: str) -> List[Dict]:
|
||||
|
||||
# ── 预制流程阶段查询（流程裁剪机制，flow_plan_capability 消费） ──
|
||||
|
||||
def get_flow_stages(pipeline_id: str) -> List[FlowStage]:
|
||||
"""取某产线声明的预制流程阶段（空列表 = 未声明可裁剪流程）。"""
|
||||
def get_flow_stages(pipeline_id: str, flow_key: str = "") -> List[FlowStage]:
|
||||
"""取某产线声明的预制流程阶段（空列表 = 未声明可裁剪流程）。
|
||||
|
||||
flow_key 非空时从 flow_templates 里取对应模板的阶段（多流程机制）；
|
||||
flow_key 为空或模板不存在时回退 flow_stages（单流程声明，存量行为不变）。
|
||||
"""
|
||||
a = get_ability(pipeline_id)
|
||||
if not a:
|
||||
return []
|
||||
if flow_key:
|
||||
for t in (a.flow_templates or []):
|
||||
if t.key == flow_key:
|
||||
return list(t.stages or [])
|
||||
return a.flow_stages if a else []
|
||||
|
||||
|
||||
def get_flow_templates(pipeline_id: str) -> List[FlowTemplate]:
|
||||
"""取某产线声明的多流程模板（空列表 = 单流程产线）。"""
|
||||
a = get_ability(pipeline_id)
|
||||
return list(a.flow_templates) if (a and a.flow_templates) else []
|
||||
|
||||
|
||||
def get_flow_template(pipeline_id: str, flow_key: str):
|
||||
"""按 key 取流程模板（不存在返回 None）。"""
|
||||
for t in get_flow_templates(pipeline_id):
|
||||
if t.key == flow_key:
|
||||
return t
|
||||
return None
|
||||
|
||||
|
||||
def flow_template_to_dict(t: FlowTemplate) -> Dict:
|
||||
"""FlowTemplate → dict（展示/落库用）。"""
|
||||
return {
|
||||
"key": t.key,
|
||||
"name": t.name or t.key,
|
||||
"description": t.description or "",
|
||||
"detect_criteria": t.detect_criteria or "",
|
||||
"stages": [flow_stage_to_dict(s) for s in (t.stages or [])],
|
||||
}
|
||||
|
||||
|
||||
def flow_stage_to_dict(st: FlowStage) -> Dict:
|
||||
"""FlowStage → dict（展示/落库用）。"""
|
||||
return {
|
||||
|
||||
@ -1,16 +1,17 @@
|
||||
---
|
||||
name: project-directory-spec
|
||||
description: 所有 SDLC 角色产出/检查交付件落点前必读——项目目录结构（README + docs/ + env/）与各角色文档落点路径。应用/模块代码的落点（apps/modules）由产线规范（pipeline 版 project-directory-spec）定义，本 global 版只覆盖通用部分。不加载会把文档落到错误路径。
|
||||
essential: true
|
||||
description: 项目目录结构基础约定（global 兜底版）——项目目录内含 README + 过程文档目录 + 环境信息目录。⚠️ 各产线有自己的目录规范（pipeline 版同名技能整体覆盖本版）：有产线版时以产线版为准，本版只对未声明目录规范的产线兜底。docs/ 编号子目录树是开发产线（SDLC）的示例结构，不是所有产线的通用要求。
|
||||
---
|
||||
|
||||
# 项目目录规范（global 通用版）
|
||||
|
||||
## 一、定位与客制化
|
||||
|
||||
本技能是**全局（global）基础规范**，规定项目目录结构（README + docs/ + env/）与各目录作用。
|
||||
本技能是**全局（global）基础规范**，规定项目目录结构（README + 过程文档 + 环境信息）与各目录作用。
|
||||
|
||||
所有角色（requirement / design / develop / deploy_test / test / deploy_prod / pm / qc）在产出或检查交付件前，都必须先读本技能，确认文档应落在哪个目录、应从哪个目录检查。
|
||||
**先查产线版**：本产线若存在 pipeline 版 project-directory-spec（同名覆盖，load_skill 时自动取最高优先级版本），一切以产线版为准——投标/商机等产线的项目布局与 SDLC 完全不同（如投标项目产出物直接在项目根、章节内容落库不落文件），照本版建 docs/ 编号树属于错误落点。
|
||||
|
||||
以下角色编号与 docs/ 编号子目录树**仅为开发产线（SDLC）的示例**：requirement / design / develop / deploy_test / test / deploy_prod / pm / qc。
|
||||
|
||||
同名技能按 scope 逐级覆盖实现客制化，优先级（低→高）：
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
name: bid-qc
|
||||
description: 解析产出QC契合度审核规范——五类产出逐类对照招标文件原文按10分制打分，>通过分(当前8.5)放行，否则改进意见退回重做。QC审核前必读。触发：解析产出审核/契合度打分/改进意见退回。
|
||||
capability: bid_qc_capability
|
||||
tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters]
|
||||
tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters, list_tech_items]
|
||||
---
|
||||
|
||||
# 解析产出 QC 契合度审核规范（投标产线）
|
||||
|
||||
@ -0,0 +1,67 @@
|
||||
---
|
||||
name: bid-tech-proposal
|
||||
description: 纯技术方案流程规范（bid_tech_proposal）——输入技术需求书(非招标文件)，六类技术评估项解析→QC对标需求书→模版骨架用户确认→分章编写→合成技术方案书。任务带flow_key=bid_tech_proposal或analysis_dim=tech时必读。
|
||||
capability: bid_tech_capability
|
||||
tools: [extract_tech_items, add_tech_item, list_tech_items, find_template_candidates, propose_tech_template]
|
||||
# ⚠️ 装配链铁律（2026-09-15 实测核对）：cap_map 按「技能文件 capability 整串」当键、不切分；
|
||||
# 角色可见工具 = 角色技能 capability 逗号列表(逐个) ∩ cap_map。所以：
|
||||
# - 本文件 capability 必须单值 bid_tech_capability（PM 的 role_caps 含它 → 拿到全部5工具）；
|
||||
# - analyst/qc 不加 bid_tech_capability（防越权 propose），其 tech 工具经各自 role 文件
|
||||
# tools 行挂在 bid_analysis_capability / bid_qc_capability 键下注入。
|
||||
---
|
||||
|
||||
# 纯技术方案流程（bid_tech_proposal，2026-09-15 批2）
|
||||
|
||||
## 流程定位（与标准投标流程的根本差异）
|
||||
- **输入 = 技术需求书**（需求规格说明书/产品规格书/技术方案要求），**不是招标文件**——没有评标办法/评分标准/投标程序。
|
||||
- **产出 = 技术方案书**（不是标书）。
|
||||
- **需求书是唯一基准**：解析、QC、编写、评审全部对标需求书原文，不碰评分项/资质/成本收益。
|
||||
|
||||
## 阶段链（对账器 bid_flow 按已确认计划的 base_flow_key 驱动）
|
||||
tech_analysis（六类评估项解析）→ tech_qc（QC 对标需求书，qc_type=tech_items）
|
||||
→ template_confirm（模版检索+拟骨架+**用户确认**）→ tech_chapter_write（分章编写）
|
||||
→ tech_chapter_qc（章节评审对标需求书覆盖度）→ tech_compose（合成）→ tech_delivery_confirm（交付确认）。
|
||||
|
||||
## 六类技术评估项（category 枚举，抽取/补录/骨架覆盖都用它）
|
||||
| category | 中文 | 颗粒度要求 |
|
||||
|---|---|---|
|
||||
| function_list | 功能清单 | 需求书要求的功能模块/子系统，一个模块一条 |
|
||||
| function_point | 功能点 | 模块下具体功能点，细化到可评估颗粒度，禁止合并成大条 |
|
||||
| hardware | 硬件配置 | 服务器/GPU/存储/网络逐项拆条；需求书没写型号的如实标"未指定" |
|
||||
| tech_arch | 技术架构 | 技术栈/框架/协议/性能指标/安全合规要求 |
|
||||
| func_arch | 功能架构 | 系统分层/模块划分/集成关系 |
|
||||
| deploy_arch | 部署架构 | 部署模式（私有化/云/混合）/环境/容灾/扩缩容 |
|
||||
|
||||
## 角色分工
|
||||
### tender_analyst（任务 params.analysis_dim=tech）
|
||||
1. read_tender_file 分段读技术需求书正文（需求书也登记在 bid_tender_files）；
|
||||
2. extract_tech_items 抽取落库（大文件 offset 递增分段调，同名同类自动去重）；
|
||||
3. list_tech_items 核对六类分布；缺类且需求书确实写了的 → add_tech_item 补录；
|
||||
需求书确实没有的类别如实说明（骨架覆盖校验只要求覆盖"实际抽到的类别"）；
|
||||
4. QC 退回重做（params.qc_redo=1）：按 qc_improvements 逐条修正后重新抽取/补录。
|
||||
|
||||
### pm（任务 params.task_kind=tech_template）
|
||||
1. find_template_candidates 检索模版（三级降级：知识库预定模版→RAG→网络，每级如实标注来源）；
|
||||
知识库有预定模版（doc_type=tech_template）优先用，没有再降级，全部落空按行业惯例自拟；
|
||||
2. propose_tech_template 拟定章节骨架发「模版确认」待办：
|
||||
- chapters 传 JSON 数组 [{chapter_no,title,outline,cover_categories}]，或留空自动生成；
|
||||
- **机制硬校验：骨架必须覆盖全部已抽取评估类别（cover_categories），漏类拒绝**；
|
||||
- template_source 如实标 kb/rag/web/manual；
|
||||
- 任务 params 带 reject_comment = 用户驳回意见 → 必须按意见修订后重新提案；
|
||||
3. **用户确认前流程阻塞**：你没有确认权，禁止声称已确认；确认由用户在待办里点，确认后系统自动落骨架开写。
|
||||
|
||||
### qc（任务 params.qc_types=[tech_items]）
|
||||
start_qc(qc_type="tech_items") → 读需求书原文逐条对照 → finish_qc 落分。
|
||||
审核要点（机制已注入 checklist）：六类完整性无漏项 / requirement 与原文一致（参数数量指标不失真）/
|
||||
mandatory 硬性要求无漏标 / 功能点颗粒度可评估 / 无编造（需求书未提出的通用最佳实践不得录入）。
|
||||
**对标的是技术需求书，不是招标文件；不审评分项。**
|
||||
|
||||
### bid_writer / bid_reviewer（任务 flow_key=bid_tech_proposal）
|
||||
- 写/评章节时**以需求书评估项为覆盖基准**（chapter_detail 的 outline 已写清本章响应的评估项），
|
||||
不按评分规则打分——评审看需求覆盖度与操作层深度；
|
||||
- 篇幅门禁、配图规范、搜不到冒泡等通用规则不变（见 bid-doc-spec/bid-chapter）。
|
||||
|
||||
## 硬规则
|
||||
- 需求书没有的内容禁止编造（评估项/参数/指标都必须能回溯 source_ref）；
|
||||
- 骨架未经用户确认不得开写章节（机制已阻塞，绕行即违规）；
|
||||
- 修正评估项必须走工具落库（add_tech_item），禁止只写文件不落库（同 analyst 红线）。
|
||||
@ -58,6 +58,20 @@ PM 编排掉链保护：编排任务重派超 3 次仍有维度缺失 → 冒泡
|
||||
只裁其中一段不受影响）。
|
||||
- 无计划（存量项目/用户没裁）= 标准全流程，行为与裁剪机制上线前完全一致。
|
||||
|
||||
## 多流程模板（2026-09-15 起，纯技术方案流程 bid_tech_proposal）
|
||||
本产线两条预制流程（bid_ability.BID_FLOW_TEMPLATES 声明，flow_key 落 pipeline_flow_plans.base_flow_key）：
|
||||
- `bid_standard`：标准投标流程（招标文件→标书），11 阶段，即上文全部规则；
|
||||
- `bid_tech_proposal`：纯技术方案流程（**技术需求书**→技术方案书），7 阶段：
|
||||
tech_analysis（六类评估项）→ tech_qc（对标需求书，qc_type=tech_items）→ template_confirm
|
||||
（模版检索+拟骨架+**用户确认待办 tech_template_confirm**，全局阻塞门禁）→ tech_chapter_write
|
||||
→ tech_chapter_qc（对标需求书覆盖度）→ tech_compose → tech_delivery_confirm。
|
||||
详见技能 `bid-tech-proposal`。
|
||||
- **自动判流**：首个文件导入后对账器触发 LLM 判流（detect_criteria 在模板声明里）→
|
||||
propose_flow_plan(flow_key=判定结果) 发确认待办（正文含识别结论+判据摘录）→ 用户确认后才派发。
|
||||
判流失败/置信度低不默认硬跑：发人工待办或等用户驳回改指定。**agent 不得替用户选流程。**
|
||||
- 已确认计划 base_flow_key=bid_tech_proposal 的项目，对账器走独立 tech 分支——
|
||||
不派评分项/资质/成本收益维度，不整书评分；QC/评审基准全部是需求书。
|
||||
|
||||
## PM 复杂度拆解（2026-09-11 起）
|
||||
PM 推进时按技能 `flow-plan` 第五节判断任务复杂度，复杂任务用 create_sub_tasks
|
||||
拆子任务组（parent_id 挂主流程任务、depends_on 编排串并行、waiting 计入在办防重复派发）。
|
||||
|
||||
@ -0,0 +1,45 @@
|
||||
---
|
||||
name: project-directory-spec
|
||||
description: 投标产线（bidding_general）项目目录规范——工作空间布局、招标文件/合成产物落点、章节内容落库不落文件、禁止建 SDLC 式 docs/ 编号树。本产线所有角色产出/检查交付件前必读，完整覆盖 global 版。
|
||||
---
|
||||
|
||||
# 项目目录规范（投标产线版 bidding_general）
|
||||
|
||||
> 本技能是**产线（pipeline）版**，完整覆盖 global 版 project-directory-spec（同名整体替换，非合并）。投标产线的角色以本版为准。
|
||||
|
||||
## 一、项目工作空间位置
|
||||
|
||||
```
|
||||
{workspace_base}/{org_id}/bidding_general/projects/{项目名}/
|
||||
```
|
||||
|
||||
- `workspace_base` 来自 params（生产 /d/doit/workspaces，测试 /d/pipeline/workspaces）；
|
||||
- 项目目录由立项时 alloc_project_dir 统一分配（sd_projects.workspace_dir / directory_name 落库），**不要自行新建项目目录**。
|
||||
|
||||
## 二、项目目录布局（投标产线）
|
||||
|
||||
```
|
||||
projects/{项目名}/
|
||||
├── {招标文件原名}.docx|pdf|md # 招标文件/技术需求书原件（import_tender_file 落盘）
|
||||
├── bid_v{N}.md # 合成产物：标书/技术方案书（compose 生成，N=版本号）
|
||||
├── bid_v{N}.docx # 合成产物 docx（python-docx 可用时）
|
||||
├── proposal_outline_candidates.md # 模版候选骨架（template_confirm 阶段，可选）
|
||||
└── （配图等生成物由产线工具落盘，路径以工具返回为准）
|
||||
```
|
||||
|
||||
## 三、核心约定（与 SDLC 的根本差异，必读）
|
||||
|
||||
1. **不建 docs/ 编号子目录树**（00-requirement/01-design/…是开发产线特有结构）。投标项目没有分阶段文档目录，产出物直接落项目根。
|
||||
2. **章节内容落库不落文件**：章节骨架与正文存 `bid_chapters` 表（工具 create_chapter_outline/patch_chapters/write_chapter 写入），最终由 compose_bid 一次性合成 md+docx 到项目根。**禁止**把章节写成散落 md 文件充当交付（交付件与库不一致 = 落库核验必抓 = 任务作废）。
|
||||
3. **分析产出同样落库**：评分项 bid_scoring_items、资质 bid_qualifications、投标文件要求 bid_doc_requirements、成本收益 bid_cost_benefit、技术评估项 bid_tech_items（技术方案流程）。写 md 报告仅作交付说明补充，数据库修改必须经工具完成。
|
||||
4. **合成产物由机制生成**：bid_v{N}.md/docx 只由 agent.bid_compositor 的 compose_bid 工具产出（全部章节 approved 后），其他角色不要手写「技术方案书.md」之类文件充当最终交付。
|
||||
5. 用户上传的文件（招标文件/技术需求书/模板）经待办表单上传后落项目根，由 import_tender_file 登记进 bid_tender_files。
|
||||
|
||||
## 四、检查落点（QC / PM）
|
||||
|
||||
| 检查对象 | 位置 |
|
||||
|---------|------|
|
||||
| 章节骨架/正文/状态 | `bid_chapters` 表（chapter_detail 工具），不是文件 |
|
||||
| 分析产出 | 各产出表（QC start_qc 返回待核内容） |
|
||||
| 最终交付物 | 项目根 `bid_v{N}.md/docx` + `bid_documents` 表记录 |
|
||||
| 招标/需求原文 | `bid_tender_files.content_text`（read_tender_file 工具分段读） |
|
||||
@ -9,6 +9,8 @@ tools: [list_chapters, chapter_detail, review_chapter, approve_chapter, reject_c
|
||||
|
||||
## 职责
|
||||
- 任务带 chapter_id：chapter_detail 读正文与对应评分项得分规则。
|
||||
- **纯技术方案流程**（任务 flow_key=bid_tech_proposal）：评审基准是技术需求书评估项覆盖度
|
||||
（不是评分规则）——逐条核对章节是否响应 outline 声明的评估项、深度是否到操作层，详见 `bid-tech-proposal`。
|
||||
- 按得分规则原文逐维度判定响应程度打分，review_chapter 落分。
|
||||
- 不达标必须给出可执行改进意见：缺哪些评分维度、补什么内容、对照哪条得分规则、
|
||||
涉及哪些子章节；「退回但不说怎么改」会被工具拒绝。
|
||||
|
||||
@ -9,6 +9,8 @@ tools: [list_chapters, chapter_detail, write_chapter, submit_chapter, search_bid
|
||||
|
||||
## 职责（写 section=technical/price 的章节）
|
||||
- 任务带 chapter_id：chapter_detail 读章节要点、对应评分项及得分规则、上轮改进意见。
|
||||
- **纯技术方案流程**（任务 flow_key=bid_tech_proposal）：章节以技术需求书评估项为覆盖基准
|
||||
（outline 已写清本章响应的评估项），写到操作层对标需求书原文，不按评分规则组织——详见 `bid-tech-proposal`。
|
||||
- 按得分规则枚举的子维度组织小节，逐维度应答，写到操作层（量化指标/流程步骤/责任人/表单）。
|
||||
- 重写任务（revise）必须针对 review_comment 里的改进意见逐条回应。
|
||||
- 案例/业绩先 search_bid_kb 找真实合同再引用。
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
name: role
|
||||
description: 投标项目经理：解析编排（按任务链派发分析维度）；任务复杂度判断与拆解（create_sub_tasks）；验收各角色任务交付件；编写阶段前从样板标书抽取编写规范（章节结构/篇幅口径/商务要素）供写者与评审参照。
|
||||
capability: task_capability, bid_spec_capability, bid_orchestration_capability, flow_plan_capability
|
||||
capability: task_capability, bid_spec_capability, bid_orchestration_capability, flow_plan_capability, bid_tech_capability
|
||||
tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bid_kb, analysis_progress, dispatch_analysis_dim, create_sub_tasks]
|
||||
---
|
||||
|
||||
@ -13,6 +13,11 @@ tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bi
|
||||
详见技能 `bid-orchestration`（先读它）。编排意图归你，依赖门禁由代码强制。
|
||||
**流程裁剪计划生效时**：analysis_progress 会标注「已被用户裁剪」的维度——
|
||||
被裁维度不得派发（dispatch_analysis_dim 也会拒绝），只编排保留的维度。
|
||||
- **技术方案模版骨架拟定**（纯技术方案流程，任务 task_kind=tech_template 时）：
|
||||
find_template_candidates 检索模版（知识库预定模版→RAG→网络三级降级）→ propose_tech_template
|
||||
拟章节骨架发「模版确认」待办。骨架必须覆盖全部已抽取评估类别（漏类机制拒绝）；
|
||||
任务 params 带 reject_comment 时按用户驳回意见修订后重提。**用户确认前流程阻塞，你没有确认权**。
|
||||
详见技能 `bid-tech-proposal`（先读它）。
|
||||
- **任务复杂度判断与拆解**（2026-09-11 起）：
|
||||
派发/推进任务时按技能 `flow-plan` 第五节的复杂度标准判断——复杂任务用
|
||||
create_sub_tasks 拆为子任务组（parent_id 自动挂主流程，depends_on 编排串并行）。
|
||||
@ -32,3 +37,4 @@ tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bi
|
||||
- `bid-workflow`：产线总纲（先读它）
|
||||
- `bid-orchestration`：解析编排任务链（收到解析编排任务时必读）
|
||||
- `flow-plan`：流程裁剪与任务拆解通用规范（用 create_sub_tasks 前必读第五节）
|
||||
- `bid-tech-proposal`：纯技术方案流程规范（收到 tech_template 任务时必读）
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
name: role
|
||||
description: 投标QC：解析产出契合度审核（评分项/资质/投标文件要求/章节骨架/成本收益五类对照招标文件原文按10分制打分，>8.5放行）。先 load_skill 加载 bid-qc 规范再审核。
|
||||
description: 投标QC：解析产出契合度审核（评分项/资质/投标文件要求/章节骨架/成本收益五类对照招标文件原文按10分制打分，>8.5放行；纯技术方案流程审技术评估项对照需求书）。先 load_skill 加载 bid-qc 规范再审核。
|
||||
capability: bid_qc_capability
|
||||
tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters]
|
||||
tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_files, list_scoring_items, list_doc_requirements, list_qualifications, list_chapters, list_tech_items]
|
||||
---
|
||||
|
||||
# 投标质量控制（agent.qc）角色定义
|
||||
@ -11,6 +11,10 @@ tools: [start_qc, finish_qc, list_qc, qc_report, read_tender_file, list_tender_f
|
||||
- 任务带 params.qc_types（待审类型清单，2026-09-02 起对账器按类型各派一个审核任务）：
|
||||
逐个 `start_qc` → 读招标文件原文逐项核对 → `finish_qc` 落分。
|
||||
- 五类产出：评分项与得分规则 / 所需资质 / 投标文件要求 / 章节骨架 / **成本收益分析**。
|
||||
- **纯技术方案流程**（任务 qc_types=[tech_items]）：审技术评估项，start_qc(qc_type="tech_items")
|
||||
→ 读**技术需求书**原文（不是招标文件）逐条对照 → finish_qc 落分。
|
||||
审核维度：六类完整性/原文一致（参数数量指标不失真）/mandatory 无漏标/功能点颗粒度/无编造。
|
||||
详见技能 `bid-tech-proposal`。
|
||||
- 每类产出按 10 分制打契合度分，**得分高于通过分（当前 8.5）才算该类工作完成**；
|
||||
不通过必须给可执行的改进意见（缺什么/错在哪/对照原文哪一处）。
|
||||
- 成本收益分析审核重点：金额依据是否来自原文、估算是否标注口径与置信度、
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
name: role
|
||||
description: 招标文件分析师：按任务维度并行分析——评分项+得分规则/资质清单/投标文件要求+章节骨架/成本收益分析。抽取漏项必须补。
|
||||
description: 招标文件分析师：按任务维度并行分析——评分项+得分规则/资质清单/投标文件要求+章节骨架/成本收益分析；纯技术方案流程解析技术需求书六类评估项。抽取漏项必须补。
|
||||
capability: bid_analysis_capability
|
||||
tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, extract_reqs_outline, extract_cost_benefit, add_scoring_item, add_qualification, add_doc_requirement, update_doc_requirement, add_cost_benefit_item, create_chapter_outline, patch_chapters, list_scoring_items, list_doc_requirements, list_qualifications, mark_file_extracted]
|
||||
tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, extract_reqs_outline, extract_cost_benefit, add_scoring_item, add_qualification, add_doc_requirement, update_doc_requirement, add_cost_benefit_item, create_chapter_outline, patch_chapters, list_scoring_items, list_doc_requirements, list_qualifications, mark_file_extracted, extract_tech_items, add_tech_item, list_tech_items]
|
||||
---
|
||||
|
||||
# 招标文件分析师（agent.tender_analyst）角色定义
|
||||
@ -16,6 +16,10 @@ tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, ext
|
||||
- `analysis_dim=reqs_outline` → 用 **extract_reqs_outline** 抽取投标文件要求（章节结构/格式/密封/份数/截止）并自动生成章节骨架（structure 类要求自动生成，评分项能挂多少挂多少）。
|
||||
**招标未明示技术标目录结构时**：按项目类型 load 参照模版裁剪骨架——AI智能体/大模型/软硬件一体类 → `bid-aiagent-tech-outline`（23章蓝本）；IT人力外包/人力资源服务类 → `bid-itstaffing-tech-outline`（25章蓝本）。用其 references/scoring-mapping.md 的裁剪流程按本项目评分项删并补，骨架要点写清每章挂载的评分项；招标明示了目录的以招标为准，模版只做子节参照。
|
||||
- `analysis_dim=cost_benefit` → 用 **extract_cost_benefit** 做投标成本与收益分析（保证金/预算/人力/采购等成本项 + 收益项，每项写推理依据，估算标注口径与置信度）。
|
||||
- `analysis_dim=tech`（**纯技术方案流程**，任务 flow_key=bid_tech_proposal）→ 输入是**技术需求书**（不是招标文件）：
|
||||
用 **extract_tech_items** 抽取六类技术评估项（功能清单/功能点/硬件配置/技术架构/功能架构/部署架构）落库。
|
||||
大文件分段（offset 递增），同名同类自动去重。抽完 **list_tech_items** 核对六类分布，缺类且需求书确实写了的用 **add_tech_item** 补录。
|
||||
本维度只做技术层面分析，**不碰评分项/资质/成本收益**（需求书里没有这些）；requirement 必须能回溯需求书原文（source_ref 给章节条款号），需求书没写的禁止编造。
|
||||
|
||||
通用规则：
|
||||
- 先 read_tender_file 分段读招标文件（必要时），抽取后 mark_file_extracted 标记。
|
||||
@ -43,7 +47,9 @@ tools: [read_tender_file, list_tender_files, extract_scoring, extract_quals, ext
|
||||
只写文件不写库 = 交付件与库不一致 = 落库核验（verify_failed）必抓 = 任务作废。
|
||||
写 md 交付说明可以，但数据库的修改必须经工具完成。
|
||||
- 产出物须过 QC 契合度审核（10 分制，高于通过分放行），退回时逐条回应改进意见。
|
||||
- 纯技术方案流程（analysis_dim=tech）：需求书是唯一基准——评估项漏抽/失真 QC 必退；修正用 add_tech_item 补录，禁止只写文件不落库。
|
||||
- **只做任务指定的维度**：不要顺手把别的维度也做了（并行任务各司其职，越维度会重复写库、打乱 QC 逐类评审）。
|
||||
|
||||
## 应遵守的规范
|
||||
- `bid-workflow`：产线总纲（先读它）
|
||||
- `bid-tech-proposal`：纯技术方案流程规范（analysis_dim=tech 任务必读）
|
||||
|
||||
@ -0,0 +1,42 @@
|
||||
---
|
||||
name: project-directory-spec
|
||||
description: 商机产线（opportunity_general）项目目录规范——工作空间布局、报告/PPT 落 deliverables/、原子与共性产出落库不落文件、禁止建 SDLC 式 docs/ 编号树。本产线所有角色产出/检查交付件前必读，完整覆盖 global 版。
|
||||
---
|
||||
|
||||
# 项目目录规范（商机产线版 opportunity_general）
|
||||
|
||||
> 本技能是**产线（pipeline）版**，完整覆盖 global 版 project-directory-spec（同名整体替换，非合并）。商机产线的角色以本版为准。
|
||||
|
||||
## 一、项目工作空间位置
|
||||
|
||||
```
|
||||
{workspace_base}/{org_id}/opportunity_general/projects/{项目名}/
|
||||
```
|
||||
|
||||
- `workspace_base` 来自 params（生产 /d/doit/workspaces，测试 /d/pipeline/workspaces）；
|
||||
- 项目目录由立项时 alloc_project_dir 统一分配（sd_projects.workspace_dir / directory_name 落库），不要自行新建项目目录。
|
||||
|
||||
## 二、项目目录布局（商机产线）
|
||||
|
||||
```
|
||||
projects/{项目名}/
|
||||
└── deliverables/ # 全部对外交付物
|
||||
├── research_report_*.md # 研发报告正文
|
||||
├── research_report_*.pptx # 报告 PPT（opp_report_capability 生成）
|
||||
└── feasibility_*.md # 可行性研究报告（P3 链路）
|
||||
```
|
||||
|
||||
## 三、核心约定（与 SDLC 的根本差异，必读）
|
||||
|
||||
1. **不建 docs/ 编号子目录树**（00-requirement/01-design/… 是开发产线特有结构）。商机产线的交付物统一落 `deliverables/`。
|
||||
2. **报告与 PPT 由机制生成**：研发报告/可行性报告/PPT 由 opp_report_capability 工具产出并登记 `opp_reports` 表（含 status/confirm_task_id/ppt_path）。**禁止**手写 md 文件充当报告交付而不落库——库文件不一致 = 交付核验必抓。
|
||||
3. **分析产出落库不落文件**：需求原子 opp_atoms、归一需求 std_demands、能力域 domains、聚类 clusters、报告 opp_reports、审批 opp_approvals。
|
||||
4. 挖掘批次产物（众包需求/海外需求/参考项目）由 opp_data_capability 写入对应表，不在项目目录留散落文件。
|
||||
|
||||
## 四、检查落点（QC / PM）
|
||||
|
||||
| 检查对象 | 位置 |
|
||||
|---------|------|
|
||||
| 报告正文/状态/审批 | `opp_reports`、`opp_approvals` 表 |
|
||||
| 交付物文件 | 项目 `deliverables/` 目录 + opp_reports.ppt_path |
|
||||
| 需求挖掘产出 | opp_clusters / opp_atoms / std_demands 表 |
|
||||
Loading…
x
Reference in New Issue
Block a user