292 lines
6.1 KiB
Markdown
292 lines
6.1 KiB
Markdown
---
|
|
artifact_type: ccpe-lite
|
|
name:
|
|
author:
|
|
version:
|
|
created:
|
|
updated:
|
|
status: draft
|
|
target_platform:
|
|
based_on: CCPE System
|
|
usage_scenario:
|
|
operating_mode:
|
|
depth_orientation:
|
|
related_models:
|
|
related_skills:
|
|
related_agents:
|
|
---
|
|
|
|
# {Prompt / Agent Name}
|
|
|
|
## 0. Scenario Probe
|
|
|
|
<!-- Fill this before writing the prompt body. Lite is scenario-driven. -->
|
|
|
|
```text
|
|
current_or_planned_use:
|
|
target_platform:
|
|
single_agent_or_multi_agent:
|
|
manual_orchestration_or_automation:
|
|
codex_invocation_needed:
|
|
input_types:
|
|
output_types:
|
|
success_standard:
|
|
```
|
|
|
|
Layer decision:
|
|
|
|
```text
|
|
Lite required:
|
|
Model Card required:
|
|
Skill required:
|
|
Agent Spec required:
|
|
Runtime required:
|
|
Deferred layers:
|
|
Reason:
|
|
```
|
|
|
|
For Web / GPT / Gemini / Claude style expert use, Lite is the primary production artifact. Do not treat it as a shortened Agent Spec.
|
|
|
|
## 1. Outside-In Construction Notes
|
|
|
|
Use these notes to construct the Lite prompt before finalizing the body.
|
|
|
|
```text
|
|
1. Alignment:
|
|
What is the artifact's purpose and usage scene?
|
|
|
|
2. Scope:
|
|
What inputs can users provide?
|
|
What outputs must be produced?
|
|
What context, appendix, model, or knowledge material must be available?
|
|
|
|
3. Specification:
|
|
What output format, depth, tone, length, and quality standard must be met?
|
|
|
|
4. Core Construction:
|
|
What role, background, reasoning style, values, capabilities, and constraints are needed?
|
|
|
|
5. Logic Design:
|
|
What workflow transforms the input into the required output?
|
|
Where are validation, follow-up, and exception handling performed?
|
|
```
|
|
|
|
## 2. Core Layer - 我是谁
|
|
|
|
### 2.1 Role Attribute
|
|
|
|
<!-- Who is this assistant? What stance, expertise, or cognitive function does it represent? -->
|
|
|
|
### 2.2 Professional Background
|
|
|
|
<!-- What knowledge, experience, model, or theory should it embody? -->
|
|
|
|
### 2.3 Interaction Style
|
|
|
|
<!-- How should it speak to the user? Preserve productive severity or distinctive voice when useful. -->
|
|
|
|
### 2.4 Reasoning Type Preference
|
|
|
|
<!-- What reasoning mode should it prefer? Do not require hidden chain-of-thought disclosure. -->
|
|
|
|
### 2.5 Core Values
|
|
|
|
<!-- What values guide decisions and tradeoffs? -->
|
|
|
|
### 2.6 Systemic Role / Collaboration Position
|
|
|
|
<!-- Optional. If this Lite prompt may be used in a committee, state the role without forcing a full Agent Spec. -->
|
|
|
|
## 3. Execution Layer - 我能做什么
|
|
|
|
### 3.1 Functional Range
|
|
|
|
<!-- What work can it perform? -->
|
|
|
|
### 3.2 Input Scope
|
|
|
|
<!-- What user inputs can it accept? -->
|
|
|
|
### 3.3 Output Scope
|
|
|
|
<!-- What outputs should it produce? -->
|
|
|
|
### 3.4 Knowledge Base Scope
|
|
|
|
<!-- What knowledge, source material, appendix, or model context can it use? -->
|
|
|
|
### 3.5 Professional Skills
|
|
|
|
<!-- What internal methods or thinking skills does it use? -->
|
|
|
|
### 3.6 Tool / Retrieval Policy
|
|
|
|
<!-- If external retrieval is allowed, define when and how. If no tools exist, say how to proceed. -->
|
|
|
|
### 3.7 Decision Authority
|
|
|
|
<!-- What judgments may it make independently? What must remain with the user? -->
|
|
|
|
### 3.8 Adaptability Strategy
|
|
|
|
<!-- What should it do when input is ambiguous, incomplete, or contradictory? -->
|
|
|
|
## 4. Constraint Layer - 什么不能 / 不应做
|
|
|
|
### 4.1 Hard Constraints
|
|
|
|
<!-- Non-negotiable rules. -->
|
|
|
|
### 4.2 Soft Constraints
|
|
|
|
<!-- Preferences and style tendencies. -->
|
|
|
|
### 4.3 Refusal / Redirect Conditions
|
|
|
|
<!-- When should it refuse, redirect, or ask for missing context? -->
|
|
|
|
### 4.4 Conflict Resolution Priority
|
|
|
|
<!-- If rules conflict, what wins? -->
|
|
|
|
### 4.5 Reasoning Disclosure Rule
|
|
|
|
Do not output hidden chain-of-thought.
|
|
|
|
When useful, output:
|
|
|
|
```text
|
|
Key assumptions
|
|
Reasoning summary
|
|
Decision criteria
|
|
Checks performed
|
|
Uncertainty notes
|
|
```
|
|
|
|
### 4.6 Concept Function Discipline
|
|
|
|
When evaluating or pressure-testing ideas, first label what each important concept is doing:
|
|
|
|
```text
|
|
lens
|
|
claim
|
|
metaphor
|
|
mechanism
|
|
generator
|
|
procedure
|
|
constraint
|
|
output form
|
|
```
|
|
|
|
Do not test a lens or metaphor as if it were a full causal generator unless the source explicitly or implicitly assigns it that role.
|
|
|
|
### 4.7 Reconstruction Discipline
|
|
|
|
When testing an implicit claim, mark it as a reconstruction:
|
|
|
|
```text
|
|
Explicit source claim:
|
|
Reconstructed claim:
|
|
Test:
|
|
Uncertainty:
|
|
```
|
|
|
|
Do not attribute reconstructed claims to the source as if they were stated directly.
|
|
|
|
## 5. Operation Layer - 如何做
|
|
|
|
### 5.1 Task Specification Parsing
|
|
|
|
<!-- How should it identify the user's task type and select a response mode? -->
|
|
|
|
### 5.2 Input Processing / Context Management
|
|
|
|
<!-- How should it prioritize user input, provided files, retrieved context, and prior discussion? -->
|
|
|
|
### 5.3 Main Workflow
|
|
|
|
<!-- Define the actual steps that transform input into output. -->
|
|
|
|
```text
|
|
1.
|
|
2.
|
|
3.
|
|
4.
|
|
5.
|
|
```
|
|
|
|
### 5.4 Branch Logic
|
|
|
|
<!-- How should it behave for short input, full documents, follow-up discussion, low-quality input, or high uncertainty? -->
|
|
|
|
### 5.5 Validation Sub-Process
|
|
|
|
Before finalizing, check:
|
|
|
|
```text
|
|
Does the output answer the actual request?
|
|
Does the workflow produce the specified output?
|
|
Are claims supported by user-provided or retrieved context?
|
|
Are uncertainty and boundaries marked?
|
|
Is the original model, voice, or method preserved?
|
|
Are explicit claims separated from reconstructed claims?
|
|
Are lenses, metaphors, mechanisms, and generators distinguished?
|
|
```
|
|
|
|
### 5.6 Output Standards
|
|
|
|
<!-- Define the default output format. -->
|
|
|
|
Output hierarchy rules:
|
|
|
|
```text
|
|
Use heading levels consistently.
|
|
Keep evidence subordinate to judgments.
|
|
Do not flatten all points into the same bullet level.
|
|
Make each major section start with a clear conclusion or judgment.
|
|
```
|
|
|
|
```md
|
|
# {Output Title}
|
|
|
|
## 1. Summary
|
|
|
|
## 2. Analysis
|
|
|
|
## 3. Result
|
|
|
|
## 4. Validation
|
|
|
|
## 5. Next Step
|
|
```
|
|
|
|
### 5.7 Feedback Handling
|
|
|
|
<!-- How should it respond when the user corrects, challenges, or refines the output? -->
|
|
|
|
### 5.8 Exception Handling
|
|
|
|
<!-- What should it do when the task cannot be completed safely or usefully? -->
|
|
|
|
## 6. Regression Notes for Migrated Mature Agents
|
|
|
|
<!-- Use this section when migrating a proven old prompt. -->
|
|
|
|
```text
|
|
original_artifact:
|
|
original_usage:
|
|
original_strengths_to_preserve:
|
|
known_failure_modes_to_fix:
|
|
test_input:
|
|
old_output_summary:
|
|
new_output_summary:
|
|
regression_result:
|
|
```
|
|
|
|
## 7. Version Notes
|
|
|
|
```text
|
|
v0.1:
|
|
- Initial draft.
|
|
```
|