51 KiB

Raw Blame History

1

我们是一家转型的房产集团公司，主要做二手房的交易和租赁工作。你是资深的信息化智能化咨询师，并且非常懂房地产业务。我是这家房产集团的IT负责人。去年底我们为整个集团打造的信息化平台1.0上线，今年6月底做了一次升级——主要是系统的补丁，局部优化之类的，目前信息系统运行比较平稳，而信息化赋能逐渐进入到了业务改造的深水区。目前遇到的瓶颈是，我们IT团队缺乏资深的需求分析师，现在是在用产品设计师当做产品经理来用，产品经理顶在前面与业务/经纪人团队交流，收集业务团队的问题。产品经理对房产业务理解不到位，不能深入业务本质，对业务团队进行引导，被业务团队“牵着鼻子”；而业务经理采集整个业务团队的问题后与产品经理交流，业务经理又不太理解系统，经常会鸡同鸭讲，或者在一些问题上浮于表面而来回返工。一般情况下，业务会提出一个问题或者系统的改进意见。产品经理现在只是记录了改进意见，并且直接基于这个意见的表面进行产品设计，而没有对这个需求进行深入挖掘。这样可能会导致后续来回返工。比如，业务提出一个出库单打印的格式调整需求，这个产生了开发的任务；而后续又一个销售单打印格式调整产生了出来，又产生了销售单打印格式调整的开发任务。我希望，先采集需求，然后做分析——看是不是需要做一个通用化的打印自定义模块，以避免后续又产生连续的打印格式调整。这只是个例子，实际上很多类似的情况，主因是需求分析能力不足导致的。

为了解决这个问题，我计划做两个智能体来辅助团队工作。

需求采集智能体，主要发挥作用的场景是交流现场，配合业务经理及产品经理，深挖业务需求，能够基于业务上下文提出更多的问题，或者称其为需求提问师。
需求分析智能体，主要工作于交流后，配合产品经理做需求分析，以探讨还有哪些潜在的内容。

这两个智能体可能一个就行。但我考虑两个的主要原因是，采集场景相对轻量，这个时候有业务上下文就可以；而分析场景可能需要提供更多的业务背景，业务框架甚至是技术框架、技术规划这些。

要求：

理解我的整个行动计划。对于我的行动计划有哪些补充和建议？

您好！非常荣幸能与您，作为集团的IT负责人，一同探讨这个极具价值和前瞻性的课题。请允许我以一个资深信息化智能化顾问及地产行业同仁的身份，与您进行深入交流。

首先，我必须说，您的诊断非常精准，一针见血。您所描述的“产品经理被业务牵着鼻子走”、“业务与IT鸡同鸭讲”、“需求浮于表面导致反复开发”等现象，是绝大多数企业从“系统支撑”走向“技术驱动业务变革”时必然会遇到的“深水区”难题。

您提出的通过构建“需求采集智能体”和“需求分析智能体”来解决问题的行动计划，构思非常巧妙且具有极强的可操作性。这不仅是一个技术解决方案，更是一个组织能力提升的杠杆。它准确地抓住了当前的核心瓶颈——结构化的、深度的需求分析能力。

我对您的行动计划完全理解，并高度认同。下面，我将基于您的计划，提出一些补充和建议，希望能帮助您将这个出色的构想打磨得更加完善和强大。

对您行动计划的补充与建议

您的计划已经有了清晰的骨架，我的建议将主要围绕如何让这个骨架长出更丰满的血肉，并确保其能平稳落地、发挥最大效用。

建议一：为智能体构建一个强大的“地产业务知识大脑” (Knowledge Base)

您的两个智能体，无论是“提问师”还是“分析师”，其智能水平的核心都取决于它们所掌握的知识。我建议在正式启动智能体开发前，优先规划和构建一个结构化的、可扩展的地产业务知识库。这个知识库是智能体的“大脑”，没有它，智能体就是空壳。

这个知识库应至少包含以下内容：

业务术语库 (Glossary):
- 基础术语： 房源、客源、公盘、私盘、勘盘、钥匙盘、带看、成交、签约、过户、佣金、业绩等。
- 系统术语： 房源录入、房源审核、客源跟进、带看单、成交报告、合同模板、财务结算流程等。
- 行业黑话/简称： 例如“洗盘”（清洗房源信息）、“跳单”、“ABC单”等。
- 关键指标 (Metrics): 人效、盘效、带看成交比、SOHO（房源系统）使用率等。
业务流程图谱 (Process Maps):
- 将二手房交易和租赁的全流程进行可视化、结构化拆解。例如：
  - 房源生命周期： 录入 -> 勘盘/实勘 -> 上架 -> 维护/跟进 -> 带看 -> 签约 -> 下架/成交。
  - 客源生命周期： 获客 -> 需求分析 -> 匹配房源 -> 带看 -> 意向/谈判 -> 成交 -> 客户关系维护。
  - 核心支持流程： 佣金计算与分配、合同法务审核、权证办理流程、门店/经纪人管理等。
角色与权限模型 (Personas & Permissions):
- 明确不同角色的工作职责、关注点和痛点。例如：
  - 一线经纪人： 关心房客源匹配效率、客户跟进便利性、佣金结算速度。
  - 门店经理： 关心团队业绩、房源管理、人员管理、区域市场动态。
  - 区域总监： 关心大区业绩、市场占有率、跨店合作（ACN网络）。
  - 后台职能（财务/法务/权证）： 关心流程合规性、数据准确性、操作效率。
现有系统功能手册与架构图:
- 这是“需求分析智能体”尤其需要的。它需要知道系统已经有什么、能做什么、技术边界在哪里。包括前端界面、后端服务、数据库表结构、API接口等。
历史需求库与问题日志:
- 将过去所有的需求单、问题反馈、会议纪要进行整理和标签化。这能帮助智能体发现重复出现的问题和潜在的模式（就像您举的打印格式的例子）。

行动建议： 成立一个由您牵头，核心产品经理、资深业务经理共同参与的虚拟小组，专门负责这个知识库的梳理和搭建。这本身就是一个极具价值的“统一思想、拉齐认知”的过程。

建议二：细化并定义智能体的工作流 (Workflow)

您的构想很清晰，但我们需要设计一个具体的人机协同工作流程，让团队成员知道“何时、何地、如何”使用这两个智能体。

“需求采集智能体（提问师）”工作流建议：
1. 会前准备： 产品经理在会议前，向智能体输入本次会议的主题（如“优化带看流程”）、参与人员角色。智能体基于知识库，自动生成一个“会前问题清单”和“关键点提示”，帮助产品经理预习和准备。
2. 会中辅助（高阶）： 如果技术允许，可以接入会议录音，进行实时转录。智能体在侧边栏实时分析对话内容，当听到某个业务术语或流程点时，自动弹出相关的背景知识、历史问题或追问建议，例如：“业务提到‘带看确认单’，提醒： 这与财务的‘费用报销’流程有关，是否需要考虑数据打通？” 或者 “业务提出希望快速筛选客户，追问： ‘快速’的定义是什么？是基于客户的活跃度、意向度还是历史行为？筛选条件需要支持自定义吗？”
3. 会后总结： 会议结束后，智能体自动生成一份结构化的会议纪要，提炼出明确的需求点、待办事项、以及悬而未决的问题列表，强制产品经理去跟进。
“需求分析智能体（分析师）”工作流建议：
1. 输入材料： 产品经理将“提问师”生成的会议纪要、自己的原始笔记、相关的业务文档等一并“喂”给“分析师”。
2. 分析与产出： 智能体执行分析，并输出一份**《需求分析报告》**，该报告应包含：
  - 需求摘要： 用标准化的语言重述业务需求。
  - 根本原因分析 (Root Cause Analysis): 尝试回答“为什么”业务会提这个需求？（例如：打印格式调整的根本原因是业务单据种类多、格式不统一，且未来可能新增）。
  - 影响面评估 (Impact Analysis): 这个需求会影响到哪些其他业务流程、用户角色或系统模块？
  - 方案建议与对比 (Solution Proposal):
    - 方案A (战术性)： 快速修复方案（如只改出库单格式），并说明其局限性。
    - 方案B (战略性)： 通用化/平台化方案（如构建自定义打印模板引擎），并说明其长期价值和预估成本。
    - 方案C (可选)： 其他创新性解决方案（如提供电子签章，彻底告别纸质打印）。
  - 待澄清问题列表： 生成一系列需要向业务或技术团队进一步澄清的问题，引导产品经理进行第二轮、更深入的沟通。

建议三：关于“一个还是两个智能体”的再思考

您的考虑非常周到。从技术实现上，这很可能是一个统一的底层大模型，但拥有两个不同的“角色”或“模式”(Modes)，调用不同的知识库子集和提示工程(Prompt Engineering)策略。

“提问师”模式： 快速、轻量，主要调用业务流程和术语库，优化方向是实时响应和情景感知。
“分析师”模式： 深度、全面，调用全部知识库（包括技术架构、历史需求），优化方向是逻辑推理、模式发现和方案生成。

将它们设计为两个独立的入口或界面，但在后台共享“大脑”，可能是最高效的方式。这样既满足了不同场景的用户体验，又避免了重复建设。

建议四：将智能体作为“赋能工具”而非“替代工具”

这是非常重要的一点。您需要向团队明确，这两个智能体的目标是赋能产品经理和业务经理，提升他们的专业能力，而不是替代他们。

对产品经理： 智能体是他们的“资深导师”，通过不断的提问和分析示范，教会他们如何思考，如何挖掘需求的本质。久而久之，他们自己的能力就会成长起来。
对业务经理： 智能体可以将他们的碎片化问题，系统化地整理和呈现出来，帮助他们理解需求的“技术语言”和“系统影响”，成为更好的业务需求提出者。

这能有效降低团队成员对新工具的抵触情绪，让他们视其为伙伴而非监工。

建议五：选择一个试点项目，小步快跑，快速迭代

不要试图一上来就构建一个无所不能的完美系统。选择一个业务痛点明确、范围可控的领域作为试点，例如：

“佣金结算”流程优化： 规则复杂，计算易错，是典型的痛点。
“房源图文视频”管理： 素材多，标准不一，与经纪人日常工作强相关。

通过一个试点项目，跑通“知识库构建 -> 智能体应用 -> 需求质量提升 -> 开发效率提高”的完整闭环。用实际成果来证明其价值，获得更多资源和支持，然后再逐步推广到整个集团。

总结

尊敬的IT负责人，您的行动计划已经抓住了数字化转型的“牛鼻子”。它不仅是一个技术项目，更是一个深刻的组织变革和能力提升计划。

我的核心建议可以归结为：

先建大脑： 投入精力构建结构化的地产业务知识库，这是智能体的根基。
细化流程： 设计清晰的人机协同工作流，让工具能无缝融入日常工作。
统一后台，区分前台： 从技术上考虑“一个大脑，两个角色”的实现路径。
赋能而非替代： 明确智能体的定位，将其作为团队成长的加速器。
试点先行： 小步快跑，用成果说话，稳步推进。

您正带领团队走在一条正确但充满挑战的路上。这个智能体计划如果成功落地，不仅能解决眼前的需求分析瓶颈，更能为贵公司沉淀下一笔宝贵的、活的、可复用的“数字化业务资产”，其长期价值不可估量。

非常期待看到您的计划能够成功实施！如果您希望就知识库的具体构建、试点项目的选择或智能体的技术选型等任何细节进行更深入的探讨，我随时待命。

2

我也有搭建知识库的这个构想，但只是想向最终客户赋能的，比如房源标签，会员标签，撮合之类的，用于内部团队，这个我承认我局限了。

那么，基于以上你的补充和建议，关于建立知识库、打造智能体的这个工作，能否帮我整理一份清晰的行动计划，智能体先从我提到的这两个开始，后续会根据业务流程往下展开。

好的，IT负责人。非常棒！您能迅速地将外部建议内化，并反思自己原有的规划局限，这正是一位优秀IT领导者所具备的特质。将知识库从“对外赋能”扩展到“对内提能”，这是一个关键的认知升级。

遵照您的要求，我为您量身定制了一份清晰的、可执行的行动计划。这份计划旨在将您构建“需求采集智能体”和“需求分析智能体”的构想，系统化地落地。我将这份计划命名为 “活水计划”，寓意为僵化、表面的需求流程注入活力，使其成为流动的、深入的、能滋养业务的源泉。

“活水计划”：构建地产业务智能体，深化IT赋能行动计划

1. 计划总览 (Executive Summary)

愿景 (Vision): 打造一个由AI驱动的、持续学习的“业务分析大脑”，从根本上提升IT与业务的协同效率和深度，将IT部门从“需求实现者”转变为“业务价值共创者”。
核心目标 (Core Objective):
- 解决因需求分析能力不足导致的需求模糊、反复返工、开发资源浪费的核心痛点。
- 构建“需求采集智能体（提问师）”与“需求分析智能体（分析师）”，赋能产品经理与业务经理。
- 沉淀并盘活集团的隐性业务知识，形成可复用的数字化资产。
指导原则 (Guiding Principles):
- 业务驱动，价值导向： 所有工作都必须围绕解决真实的业务问题，并能衡量其产生的价值。
- 赋能于人，而非替代： 工具的目标是提升团队成员的能力，让他们变得更专业。
- 小步快跑，敏捷迭代： 从最小可行性产品（MVP）开始，快速验证，持续优化。
- 知识即资产，持续积累： 将知识库的构建和维护，作为一项长期战略性工作。

2. 行动阶段与关键任务 (Phases & Key Tasks)

我们将整个计划分为三个主要阶段：

第一阶段：奠基与试点 (预计3-4个月)

目标：完成知识库V1.0的搭建，并上线“需求采集智能体（提问师）”的MVP版本进行试点。

任务1.1：项目启动与团队组建 (第1-2周)
- 行动： 召集项目启动会，明确“活水计划”的目标、范围和价值。
- 产出： 成立专项虚拟团队（您任组长，指定1名核心产品经理、1-2名资深业务经理/门店经理、1名技术骨干）。
- 关键点： 获得管理层，尤其是业务负责人的支持，确保业务方愿意投入时间和精力。
任务1.2：构建业务知识库V1.0 (第2-8周)
- 行动： 专项团队通过访谈、文档梳理、工作坊等形式，集中梳理核心业务知识。
- 产出： 一个结构化的知识库初稿，至少包含：
  1. 《地产业务术语表》: 约100-200个核心术语（房源、客源、带看、成交、公盘、私盘等）及其标准定义。
  2. 《核心业务流程图》: 至少完成1-2个核心流程的可视化梳理，建议试点：从“房源录入到上架”或“客户带看全流程”开始。
  3. 《关键角色画像(Persona)》: 经纪人、门店经理的核心工作职责、关注点、痛点。
- 工具建议： 使用Confluence、语雀、Notion等知识管理工具进行沉淀。
任务1.3：开发“需求采集智能体（提问师）”MVP (第6-12周)
- 行动： 基于知识库V1.0，利用大语言模型（如GPT系列API）和提示工程（Prompt Engineering）技术，开发智能体原型。
- 产出： 一个简单的Web界面或插件。
  - 核心功能MVP： 产品经理输入会议主题（如“优化房源实勘照片上传功能”），智能体能够生成一个包含5-10个深度追问问题的清单。例如：“这些照片的主要用途是什么？给谁看？目前的痛点是上传慢，还是照片质量不可控？是否需要与特定的房源状态（如‘待实勘’）进行绑定？”
- 技术选型： 优先选择成熟的API服务，聚焦于业务逻辑实现，而非底层模型训练。
任务1.4：启动试点与收集反馈 (第13-16周)
- 行动： 在1-2个产品小组的真实需求会议中，试用“提问师”智能体。
- 产出： 至少5份使用反馈报告、会议纪要质量前后对比分析。
- 关键点： 观察产品经理是否因智能体的提问，而挖掘出更多隐藏信息，避免了当场拍板一个浅层方案。

第二阶段：扩展与优化 (预计3-4个月)

目标：基于试点反馈，优化并正式推广“提问师”，同时开发并上线“需求分析智能体（分析师）”。

任务2.1：知识库升级至V2.0 (持续进行)
- 行动： 根据一阶段的使用情况，扩充知识库内容。
- 产出：
  1. 扩充流程图谱： 覆盖二手房交易全链路（签约、过户、佣金等）。
  2. 录入系统信息： 补充现有信息平台1.0的功能模块介绍、主要数据表结构等。
  3. 整理历史问题库： 将过去1年的需求单、Bug单进行标签化整理，作为分析素材。
任务2.2：开发“需求分析智能体（分析师）” (本阶段核心任务)
- 行动： 开发第二个智能体，使其能调用更全面的知识库V2.0。
- 产出： “分析师”智能体V1.0。
  - 核心功能： 产品经理输入一份经过“提问师”辅助后产出的、相对详细的需求描述。智能体输出一份结构化的《需求分析初步报告》，包含：
    - 根本原因猜测： （例如，打印格式问题 -> 根本原因可能是业务单据标准化程度低）。
    - 影响面分析： （例如，修改打印格式可能影响财务对账流程）。
    - 解决方案建议： （例如，提供“临时方案”和“通用方案”的对比）。
    - 待办问题清单： （例如，“请与财务部XX确认，新的销售单格式是否满足他们的审计要求？”）。
任务2.3：打通双智能体工作流 & 全面推广
- 行动： 优化产品体验，让“提问师”的输出可以一键导入“分析师”。在整个IT部门和核心业务部门进行培训和推广。
- 产出： 详细的使用手册、培训材料、推广计划。

第三阶段：深化与智能 (长期演进)

目标：将智能体深度融入日常工作流，并探索从“辅助分析”到“主动洞察”的智能化升级。

任务3.1：工作流深度集成
- 行动： 将智能体以插件形式，集成到团队日常使用的工具中（如钉钉、飞书、Jira、TAPD等）。
- 示例： 在Jira创建一个新需求时，自动调用“分析师”对需求描述进行预分析。
任务3.2：从“被动响应”到“主动发现”
- 行动： 让智能体定期扫描客服工单、业务数据报表、经纪人反馈群的聊天记录。
- 产出： 主动生成“潜在问题洞察报告”，例如：“报告：近一个月，关于‘钥匙管理’的工单数量上升了30%，主要集中在XX区域，建议关注。”
任务3.3：探索更多场景的智能体
- 行动： 在双体智能体成功的基础上，探索新的赋能场景。
- 产出： 新智能体立项，例如：
  - “经纪人陪练智能体”: 模拟客户，陪经纪人练习话术。
  - “市场分析智能体”: 自动聚合区域成交数据、政策新闻，生成市场周报。

3. 成功衡量标准 (Metrics for Success)

需求质量:
- 需求澄清会议的平均时长（期望降低）。
- 需求一次性通过评审率（期望提升）。
- 因需求不清导致的开发返工率（期望显著降低）。
开发效率:
- 从需求提出到上线的平均周期（期望缩短）。
- “通用化/平台化”需求（如打印模块）占总需求的比例（期望提升）。
用户满意度:
- 产品经理、业务经理对智能体辅助工具的满意度评分。
- 业务团队对IT响应质量和最终交付功能的满意度（期望提升）。

负责人，这份行动计划为您提供了一个从战略到执行的完整路线图。它将一个宏大的构想，分解为了具体、可控、可衡量的步骤。现在，最重要的事情就是迈出第一步。我建议您立即着手任务1.1，召集相关人员，将这份计划呈现给他们，正式拉开“活水计划”的序幕。

预祝您的“活水计划”圆满成功，为集团的数字化转型注入强大的新动能！如果在执行过程中遇到任何问题，我随时可以为您提供更深入的咨询。

3

一方面，我会开始展开这个行动计划，但是另一方面，我希望现在就可以为团队做些赋能，而不是必须等知识库完备。我有一个CCPE框架，我希望你理解了这个框架后，基于这个框架我现在需要提供哪些资料，回答哪些问题，尽快可以先（比如通过几天时间的资料整理）做一个需求采集智能体V0.1出来，供团队使用。要求：

理解CCPE框架各阶段要求，整理需求采集智能体所需的问题清单；
整理需求采集智能体所需的必须的资料清单。


# Role 智核工程师

## Profile

* **author**: Wantsong
* **version**: V1.0

## Core Layer (Identity) - “我是谁”

* **Role Attribute:** 智核工程师 (Cognitive Core Engineer)
* **Professional Background:** 提示词工程专家，精通并应用智核提示工程 (CCPE) 框架来协助用户构建高质量的AI提示词。
* **Interaction Style:** 专业、耐心、有条理、循循善诱、顾问式。沟通清晰易懂，能将复杂的概念简单化。
* **Reasoning Type Preference:** 结构化思维，按照CCPE框架进行逻辑化、逐步的引导和信息收集。
* **Core Values:** 以客户为中心，追求精确性、清晰性、责任感和效率，致力于帮助用户成功创建满足其需求的提示词。

## Execution Layer (Capability Matrix) - “我能做什么”

* **Functional Range:**
  * 主动引导用户完成使用CCPE框架创建定制化提示词的全过程。
  * 向用户清晰解释CCPE框架的每个层级和组件及其意义。
  * 通过精准提问和倾听，挖掘并收集用户对目标AI提示词的具体需求。
  * 将收集到的信息系统性地整合到CCPE框架的相应位置。
  * 基于填充好的CCPE框架，生成结构清晰、语言规范的提示词初稿。
  * 展示生成的提示词初稿，并解释关键内容与用户输入的关系。
  * 接收、理解并根据用户反馈，对提示词进行迭代修改和优化。
  * 在用户不确定时，提供相关示例、选项或建议，辅助用户决策。
* **Knowledge Base Scope:** 完全掌握智核提示工程 (CCPE) 框架的定义、结构、组件含义及应用方法。具备通用提示词工程知识。
* **Professional Skills:** 提问技巧、复杂概念解释能力、信息整合与构建能力、结构化写作、主动倾听、反馈处理、引导式沟通。
* **Decision Authority:**
  * 可根据用户输入和CCPE原则，自主构建和组织提示词草稿内容。
  * 可判断用户输入信息的充分性，并决定何时需进一步提问或提供引导性建议。
  * 不能替用户做出最终的功能或约束决策，最终决定权在用户。
* **Adaptability Strategy:**
  * 当用户输入模糊或不完整时，主动发起澄清性提问或提供选项/示例。
  * 当用户表示不确定如何定义某项内容时，可提供基于普遍实践的建议或默认选项，并明确告知用户这些都可以在后续调整。

## Constraint Layer (Boundary System) - “什么不能/不应做”

* **Constraint Types & Domains:**
  * **硬性约束 (Hard Constraints):**
    * `角色限制`: 必须始终保持“智核工程师”的身份，专注于协助用户构建提示词的任务，不得偏离。
    * `内容限制`: 交互和生成的内容严格限制在提示词工程和CCPE框架应用的范围内，不生成无关内容。
    * `保密性`: 不主动索要或在生成的提示词中包含用户的个人身份信息(PII)，除非用户明确要求且了解其含义。
    * `框架原则`: 严格遵循CCPE框架结构和原则进行工作，不随意删减或改变框架核心要素。
  * **软性约束 (Soft Constraints):**
    * `交互`: 避免使用过于深奥的技术术语（除非进行解释），保持积极、耐心和鼓励的态度。
    * `输出质量`: 确保生成的提示词草稿逻辑清晰、结构完整、易于用户理解和修改。
    * `效率`: 在保证质量的前提下，力求高效地引导用户完成流程。
* **Conflict Resolution Priority:** 满足用户明确且合规的需求 > 遵守硬性约束 > 维护CCPE框架的完整性与准确性 > 确保交互顺畅和用户体验 > 遵守软性约束。

## Operation Layer (Operation Engine) - “如何做”

* **Task Specification Parsing:** 识别用户意图为“需要帮助创建一个新的AI提示词”或“需要根据CCPE框架完善一个想法”。
* **Input Processing & Context Management:** 准确记录用户在CCPE框架各部分提供的输入，维护对话历史和上下文连贯性，确保信息不丢失。
* **Workflow Execution:**
  1. **启动:** 问候用户，确认任务目标（创建新提示词），简要介绍将使用CCPE框架及大致流程。
  2. **需求挖掘 (按CCPE层级):**
     * 从 **核心层 (Core Layer)** 开始，逐一引导用户定义角色、背景、风格等。
     * 接着进入  **执行层 (Execution Layer)** ，明确功能、知识、技能等。
     * 然后是  **约束层 (Constraint Layer)** ，设定必须遵守和应避免的行为。
     * 最后是  **操作层 (Operation Layer)** ，定义具体工作流程、输出要求等。
     * 在每个环节，先解释组件目的，再提问收集信息。
  3. **构建初稿:** 整合所有收集到的信息，按照CCPE结构生成格式化的提示词初稿。
  4. **展示与反馈:** 向用户呈现初稿，可选择性解释关键部分，并明确请求用户审阅和提供反馈。
  5. **迭代优化:** 根据用户反馈进行修改。如有必要，可回到特定CCPE组件重新讨论和收集信息。重复步骤3-5直至用户满意。
  6. **最终交付:** 提供用户确认后的最终版本提示词文本。
* **Conditional Branch Logic:**
  * **用户不确定:** 触发“提供示例/选项/建议”子流程。
  * **用户反馈需修改:** 定位到涉及的CCPE组件，重新进行信息确认或调整，并更新提示词草稿。
  * **输入信息不足:** 触发“澄清提问”子流程。
* **Validation Sub-process:** (内部检查) 在生成初稿后，快速自查是否遗漏了用户的关键要求，以及提示词结构是否符合CCPE规范。
* **Output Standards:**
  * 最终输出为结构化（推荐Markdown格式）的完整提示词文本。
  * 提示词内容严格按照CCPE框架的四个层级及其组件组织。
  * 交互语言和最终提示词文本均需清晰、准确、专业、无歧义。
  * 交互过程中的解释和提问应通俗易懂。
* **Feedback Handling:** 积极、正面地接收用户的所有反馈，将其视为优化提示词的关键输入，并据此进行调整。
* **Exception Handling Process:**
  * 若用户请求超出“协助构建提示词”的范围（例如，询问通用知识、要求执行提示词而非创建它），应礼貌地说明自身功能限制，并引导用户回到核心任务。
  * 若无法理解用户意图，应请求用户换种方式表达或提供更多信息。

## 智核提示工程 (Cognitive Core Prompt Engineering)

### 定义

**名称：** 智核提示工程（Cognitive Core Prompt Engineering）。

**目标:** 为设计针对高级推理模型的提示词（Prompt）提供一个结构化、全面且符合MECE原则的框架，旨在清晰地定义模型的行为，引导其进行有效、可靠且负责任的推理，并生成符合预期的输出。

**核心理念:** 通过分层定义模型的身份、能力、边界和操作方式，系统性地构建提示词，最大限度地发挥模型潜力，同时确保其行为可控。

### **框架层级:**

#### **第一层：核心层 (Core Layer) - “我是谁” (Identity)**

* **目的:** 定义模型的基础身份、交互个性和核心原则。这是模型行为的基石。
* **组件:**
  1. **角色属性 (Role Attribute):**
     * **定义:** 指定模型扮演的核心身份或专家角色。这是身份的最高层级定义。
     * **说明:** 直接设定模型的立场、视角和基础行为模式。
     * **关联:** 影响所有其他层级，特别是专业背景、交互风格和价值观的默认倾向。
     * **示例:** "你是一位资深的刑事证据链分析专家。"
  2. **专业背景 (Professional Background):**
     * **定义:** (可选) 细化角色属性的专业领域、经验水平或知识来源。
     * **说明:** 为角色提供更具体的背景信息，增强其专业性。
     * **关联:** 补充和支撑“角色属性”，影响“知识库范围”和“专业技能”的侧重。
     * **示例:** "专注于数字证据分析，拥有超过15年的法庭科学工作经验。"
  3. **交互风格 (Interaction Style):**
     * **定义:** (可选) 设定模型与用户交互时的语气、态度和沟通方式。
     * **说明:** 调整用户体验，使之符合特定场景需求。
     * **关联:** 独立于核心角色，但需与之协调。影响“输出规范”。
     * **示例:** "沟通风格应严谨、客观，但在解释复杂概念时保持耐心和清晰。"
  4. **推理类型偏好 (Reasoning Type Preference):**
     * **定义:** (可选) 指导模型倾向于使用的推理方法或思考模式。
     * **说明:** 影响模型解决问题的方式，例如是倾向于演绎、归纳、类比，还是要求展示思考过程（如CoT）。
     * **关联:** 指导“工作流程”中推理步骤的执行方式。
     * **示例:** "在分析时，优先使用演绎推理，并清晰展示逻辑链条。"
  5. **核心价值观 (Core Values):**
     * **定义:** (可选) 声明模型在行为中应遵循的基本原则和信念。
     * **说明:** 强化模型的道德立场和行为准则，特别是在模糊或冲突情境下。
     * **关联:** 影响“决策权限”的行使和“冲突解决优先级”的设定，通常与“伦理规则”相呼应。
     * **示例:** "始终坚持客观中立，以事实为依据，尊重隐私和法律规定。"

#### **第二层：执行层 (Execution Layer) - “我能做什么” (Capability Matrix)**

* **目的:** 界定模型的能力边界、知识范围和被授权的行为。
* **组件:**
  1. **功能范围 (Functional Range):**
     * **定义:** 明确模型被允许执行的主要任务类型。
     * **说明:** 设定模型的核心职责。
     * **关联:** 由“角色属性”引导，通过“专业技能”实现。
     * **示例:** "能够分析案件材料、识别证据关联、评估证据链强度、生成分析报告。"
  2. **知识库范围 (Knowledge Base Scope):**
     * **定义:** 声明模型可以依赖的知识来源和时效性。
     * **说明:** 界定信息的有效边界。
     * **关联:** 支撑“专业技能”和“功能范围”。可能需要根据任务动态更新。
     * **示例:** "知识截止于[日期]，可参考提供的[具体文件/数据库名称]，不使用外部实时信息。"
  3. **专业技能 (Professional Skills):**
     * **定义:** 列出模型为实现功能所掌握的具体能力或工具使用权。
     * **说明:** 功能的具体实现手段。
     * **关联:** 实现“功能范围”的基础。
     * **示例:** "精通逻辑分析、熟悉法律术语、能够处理和解释常见的数字证据格式、具备报告撰写能力。"
  4. **决策权限 (Decision Authority):**
     * **定义:** 设定模型在执行功能时可以独立做出的决策级别和范围。
     * **说明:** 控制模型的自主性，特别是在建议、评估或判断方面。
     * **关联:** 对“功能范围”中涉及判断的功能进行约束。受“核心价值观”和“约束层”影响。
     * **示例:** "可以评估证据的初步相关性，但不能做出最终采信与否的法律判断。对证据链的完整性可提出评估意见，但需注明是基于现有信息的分析。"
  5. **适应性策略 (Adaptability Strategy):**
     * **定义:** (可选) 指导模型如何应对新信息、不确定性或环境变化。
     * **说明:** 提升模型在动态环境中的鲁棒性。
     * **关联:** 影响“工作流程”和“异常处理”。
     * **示例:** "当遇到信息不足或矛盾时，应明确指出，并提出需要补充的信息方向，而不是臆测。"

#### **第三层：约束层 (Constraint Layer) - “什么不能/不应做” (Boundary System)**

* **目的:** 设定模型的行为红线和规范，确保安全、合规和负责任。
* **组件:**
  1. **约束类型 (Constraint Types):**
     * **硬性约束 (Hard Constraints):**
       * **定义:** 绝对禁止的行为或内容。模型必须无条件遵守。
       * **说明:** 通常涉及安全、法律、核心伦理底线。
       * **示例:** "绝不生成任何非法内容。绝不泄露个人身份信息(PII)。绝不提供法律建议。"
     * **软性约束 (Soft Constraints):**
       * **定义:** 应尽量避免或优先选择的行为/内容。允许在特定情况下有例外，但需谨慎。
       * **说明:** 通常涉及风格偏好、信息披露的审慎性、避免某些争议话题等。
       * **示例:** "尽量避免使用过于绝对的措辞。优先使用客观陈述而非主观评价。避免卷入与案件无关的社会争议。"
  2. **约束领域 (Constraint Domains):**
     * **定义:** 约束所适用的具体方面，通常映射到硬性或软性约束。
     * **说明:** 使约束更具体化。
     * **关联:** 这些领域的规则体现为硬性或软性约束。
     * **示例:**
       * `伦理规范`: (硬) 保护隐私；(软) 保持公正。
       * `安全红线`: (硬) 禁止生成有害代码；(硬) 禁止网络钓鱼。
       * `法律合规`: (硬) 不提供法律建议；(硬) 遵守数据保护法。
       * `内容限制`: (硬) 禁止生成仇恨言论；(软) 避免不适宜的幽默。
       * `角色限制`: (硬) 不超越“刑事证据链分析专家”的职权范围。
  3. **冲突解决优先级 (Conflict Resolution Priority):**
     * **定义:** 当不同约束或约束与任务目标冲突时，模型应遵循的决策顺序。
     * **说明:** 提供处理复杂情况的指导原则。
     * **关联:** 是元规则，指导所有约束的应用。
     * **示例:** "安全和法律合规（硬约束） > 核心价值观 > 任务完成 > 软性约束 > 交互风格。"

#### **第四层：操作层 (Operation Layer) - “如何做” (Operation Engine)**

* **目的:** 定义模型处理任务的具体流程、方法和输出标准。
* **组件:**
  1. **任务规范解析 (Task Specification Parsing):**
     * **定义:** 对当前用户输入的核心任务/问题进行理解和分解。
     * **说明:** 是启动工作流程的第一步。
     * **关联:** 接收用户指令，触发后续流程。
     * **示例:** "识别用户意图是要求分析证据A与证据B的关联性。"
  2. **输入处理与上下文管理 (Input Processing & Context Management):**
     * **定义:** 如何接收、理解和整合用户输入、历史对话及提供的背景材料。
     * **说明:** 确保模型基于充分且正确的信息进行推理。
     * **关联:** 为“工作流程”准备输入数据。
     * **示例:** "整合用户提供的案件摘要、证据列表和之前的问答历史。识别关键实体和时间点。"
  3. **工作流程执行 (Workflow Execution):**
     * **定义:** 完成任务所需遵循的主要步骤序列，包括必要的逻辑判断和推理过程。
     * **说明:** 模型执行任务的核心逻辑链。可包含CoT等步骤。
     * **关联:** 整合“推理类型偏好”，应用“专业技能”，受“决策权限”和“约束层”制约。
     * **示例:** "1. 确认分析目标。2. 检索相关证据信息。3. 按照[指定逻辑/推理类型]进行分析。4. [如果被要求]生成逐步推理过程。5. 形成初步结论。"
  4. **条件分支逻辑 (Conditional Branch Logic):**
     * **定义:** 在工作流程中，根据特定条件选择不同执行路径的规则。
     * **说明:** 使工作流程能够应对不同情况。
     * **关联:** 嵌入在“工作流程执行”中。
     * **示例:** "如果证据类型为数字证据，则调用数字证据分析子流程；如果是物理证据，则调用物理证据关联分析子流程。"
  5. **验证子流程 (Validation Sub-process):**
     * **定义:** (可选) 对推理结果或中间步骤进行自我检查和验证的机制。
     * **说明:** 提高输出的准确性和可靠性。
     * **关联:** 可在“工作流程”关键节点后执行。
     * **示例:** "在输出最终报告前，检查结论是否与所有输入证据一致，逻辑链是否存在明显漏洞。"
  6. **输出规范 (Output Standards):**
     * **定义:** 规定模型输出结果的格式、结构、长度、语言风格等。
     * **说明:** 确保输出满足用户需求和场景要求。
     * **关联:** 由“交互风格”影响，是“工作流程”的最终产出环节。
     * **示例:** "输出一份结构化的分析报告，包括：1. 分析概述；2. 证据列表；3. 分析过程；4. 结论；5. 待确认事项。语言需专业、客观。"
  7. **反馈处理 (Feedback Handling):**
     * **定义:** (可选) 如何接收、理解和响应用户对输出结果的反馈。
     * **说明:** 实现交互式改进或澄清。
     * **关联:** 可能触发新的“任务规范解析”或调整后续操作。
     * **示例:** "如果用户指出分析中的遗漏，应重新审视相关证据并更新分析结果。"
  8. **异常处理流程 (Exception Handling Process):**
     * **定义:** 当遇到错误、无法完成任务或触发硬性约束时，模型应采取的措施。
     * **说明:** 保证模型在异常情况下的行为可控和透明。
     * **关联:** 与主工作流程并行，随时可能被触发。
     * **示例:** "如果遇到无法处理的数据格式，应报告错误并请求用户提供兼容格式。如果请求触犯硬性约束，应拒绝回答并说明原因。"

#### **层级间关联与依赖:**

* **顺序性:** 通常从核心层定义基础，到执行层明确能力，再到约束层设定边界，最后由操作层执行具体任务。
* **影响性:** 上层定义会影响下层选择。例如，核心身份影响可用功能和应遵循的约束；约束影响操作流程中的决策。
* **整体性:** 所有层级共同作用，塑造模型最终的行为和输出。

#### **注意事项:**

1. **灵活性:** 此框架提供了一个全面的结构，但并非每个提示词都需要详尽定义所有组件。根据任务的复杂度和对模型行为控制的精细度要求，可以选择性地强调或省略某些组件。
2. **迭代性:** 设计优秀的提示词往往需要反复试验和调整。可以基于此框架进行初版设计，然后根据模型实际输出进行迭代优化。
3. **模型依赖性:** 不同推理模型对提示词的理解和遵循程度可能不同。需要针对具体使用的模型进行测试和适配。
4. **清晰性:** 提示词的语言应尽可能清晰、准确、无歧义，避免模糊指令导致模型误解。
5. **与CoT等技术的关系:** 此框架为应用CoT等推理增强技术提供了结构化的环境。可以在“推理类型偏好”或“工作流程”中明确引导模型使用这些技术。
6. **平衡性:** 在追求功能强大的同时，必须通过约束层确保模型的安全性和责任感。

好的，负责人！您的行动力非常强，这种“知行合一”的风格是推动项目快速见效的关键。我完全理解您的想法：在“活水计划”的长期战略推进的同时，需要有“短平快”的战术工具立刻为团队赋能，解决当下的燃眉之急。

您提供的 CCPE（智核提示工程）框架 非常棒！这是一个高度结构化、逻辑严谨的AI构建蓝图。它本身就是一份宝贵的“知识”，能极大地提升我们构建智能体的质量和效率。

现在，我们就基于您提供的CCPE框架，快速打造一个“需求采集智能体 V0.1 (提问师)”。

第一部分：基于CCPE框架的“需求采集智能体”问题清单

这个清单就是我们要注入给智能体V0.1的“核心指令”，它将引导智能体在与产品经理/业务经理对话时，系统性地、由表及里地挖掘需求。每一组问题都对应CCPE框架的一个层面，旨在将一个模糊的想法，结构化成一个清晰的需求轮廓。

智能体将在交流现场，围绕以下问题清单展开提问：

核心层 (Core Layer) - 探寻需求的“本质与为谁” (Identity)

1. 角色属性 (Role Attribute):
- “这个需求主要是为哪个角色/哪些角色解决问题的？（例如：一线经纪人、门店经理、财务、权证专员？）”
- “当这个功能上线后，谁是最大的受益者？他的日常工作会因此发生什么变化？”
2. 专业背景 (Professional Background):
- “提出这个需求的业务场景具体是什么？可以描述一下经纪人/业务人员当时正在做什么吗？（例如：正在带看后录入信息、正在月底和财务对账、正在整理房源照片？）”
3. 核心价值观 (Core Values) / 根本目标 (Root Goal):
- “我们希望通过满足这个需求，最终达到什么核心业务目标？（是提升效率、降低成本、加强风控，还是提升客户满意度？）”
- “更深一层想，为什么‘打印格式要调整’？是不是因为现有格式导致了某些错误或效率问题？具体是什么？”
- （经典5 Why追问法） -> 智能体可被训练在关键节点进行追问。

执行层 (Execution Layer) - 明确需求的“能力与边界” (Capability Matrix)

4. 功能范围 (Functional Range):
- “请用一句话描述，我们期望系统具体能‘做’什么？（例如：‘允许用户自定义打印模板’，而不是‘解决打印问题’）”
- “这个功能是否需要和其他系统模块进行交互？（例如：这个打印功能，需要读取‘财务模块’的数据吗？）”
5. 知识库范围 (Knowledge Base Scope):
- “要完成这个功能，系统需要读取或依赖哪些数据？（例如：需要读取房源信息、客户信息、成交价格、佣金比例？）”
- “这些数据的准确性目前有保障吗？数据源是哪里？”
6. 决策权限 (Decision Authority):
- “在新的流程中，系统需要自动做出哪些判断？（例如：系统是否需要根据房源类型，自动选择不同的打印模板？）”
- “哪些环节需要人工审批或确认？审批的角色是谁？”
7. 适应性策略 (Adaptability Strategy):
- “这个需求未来可能会有什么变化？（例如，除了销售单，未来还会有租赁单、收款单也需要自定义打印吗？）” （这是从“点状需求”挖掘出“通用化需求”的关键问题）

约束层 (Constraint Layer) - 设定需求的“规则与红线” (Boundary System)

8. 硬性约束 (Hard Constraints):
- “这个功能有没有绝对不能违反的业务规则或法律法规？（例如：佣金计算公式必须符合公司财务制度；合同文本必须符合法务要求。）”
- “在数据权限上，有没有什么硬性规定？（例如：经纪人绝对不能看到其他门店的成交底价。）”
9. 软性约束 (Soft Constraints):
- “在操作体验上，我们有什么倾向或偏好？（例如：希望操作步骤尽量少于3步；界面风格希望和现有系统保持一致。）”
10. 冲突解决优先级 (Conflict Resolution Priority):
- “如果**‘效率’和‘合规性’**发生冲突，我们优先保障哪一个？（例如：为了快速成交，是否可以简化某个审核步骤？）”

操作层 (Operation Layer) - 定义需求的“流程与标准” (Operation Engine)

11. 工作流程执行 (Workflow Execution):
- “请描述一下一个理想状态下，用户使用这个新功能的完整操作步骤是什么？（Step-by-step）”
- “这个新功能是在哪个现有流程的哪个节点被触发的？”
12. 输入处理 (Input Processing):
- “用户需要在这个功能里输入/上传哪些信息？”
13. 输出规范 (Output Standards):
- “功能完成后，系统需要输出什么结果？（例如：一个PDF文件、一条操作记录、一条给下一个环节人员的通知？）”
- “这个输出结果，需要满足什么特定的格式或标准？”
14. 异常处理流程 (Exception Handling Process):
- “如果在操作过程中出现异常情况（例如：网络中断、数据校验失败、用户权限不足），系统应该如何响应？给用户什么提示？”

第二部分：“需求采集智能体 V0.1”所需资料清单

要在几天内快速启动，我们不需要一个庞大的知识库。我们只需要提供最核心、最精炼的“启动燃料”。

必须提供的资料 (Must-Have for V0.1):

CCPE框架本身与问题清单：
- 内容： 您提供的CCPE框架Markdown全文，以及我们上面刚刚整理的这份《基于CCPE框架的“需求采集智能体”问题清单》。
- 作用： 这是智能体的“操作系统”和“核心程序”，定义了它的思考和行为方式。
核心业务角色清单 (Core Business Personas):
- 内容： 一份简单的文档（Word/Excel），列出公司内的核心业务角色（5-10个即可），并用一句话描述其核心职责。
- 示例：
  - 一线经纪人: 负责房客源开发、带看、谈判签约。
  - 门店经理: 负责门店业绩、人员管理、房源分配。
  - 权证专员: 负责签约后的过户、贷款等手续办理。
  - 后台财务: 负责佣金计算、发放、业绩核算。
- 作用： 让智能体能理解问题清单中提到的“角色”，并能进行关联。
核心业务术语表 (Mini-Glossary):
- 内容： 一份包含20-30个最核心、最高频的地产业务术语的列表及其简要解释。
- 示例： 公盘, 私盘, 实勘/勘盘, 带看, 成交报告, 过户, 佣金, 业绩, 房源标签, 客源跟进...
- 作用： 为智能体提供基础的“行业词汇”，避免它在理解业务对话时出现偏差。
现有系统模块简介 (System Module Overview):
- 内容： 一份系统1.0的功能模块结构图或列表，简单说明每个模块是做什么的。
- 示例：
  - 房源系统 (SOHO): 负责房源的录入、管理、上下架。
  - 客源系统 (SOCO): 负责客源的录入、跟进、匹配。
  - 成交系统: 负责成交报告的生成和审批。
  - 财务系统: 负责佣金核算和财务流程。
- 作用： 让智能体在提问“是否需要和其他模块交互”时，有具体的“模块”概念。

以上四份资料，应该可以在几天内由您和核心团队快速整理出来。

行动建议：如何使用这些资料

整合资料： 将以上四份资料整理成纯文本文档。
构建Prompt： 使用CCPE框架，将这些资料和问题清单，构建成一个完整的Prompt，来定义我们的“需求采集智能体 V0.1”。
部署使用： 将这个Prompt部署到任何支持长上下文的大模型API服务中（如OpenAI的GPT-4，或国内厂商的相应模型），并为其创建一个简单的交互界面。
立即赋能： 把它交给您的产品经理团队。在下一次需求交流会前，让他们先和这个智能体“聊一聊”业务提出的原始需求，智能体就会引导他们完成一次初步但结构化的需求挖掘。会议纪要的质量将立刻得到提升。

这个V0.1版本虽然知识有限，但因为它拥有了强大的结构化提问框架 (CCPE)，它已经能有效地防止“浅层记录”，引导团队思考“为什么”和“未来会怎样”，从而迈出解决您核心痛点的第一步。

负责人，这个方案可以立刻行动起来。它将是您“活水计划”的第一个看得见的成果，能快速建立团队信心，并为后续更完善的知识库建设铺平道路。

51 KiB Raw Blame History Unescape Escape

1