Most enterprise knowledge base and AI projects are doomed before construction even begins—feeding outdated, conflicting, and non-compliant corpora directly into RAG means that no matter how good the technology is, it just scales up the errors. This skill covers the complete two sections of consulting:Diagnosis sectionanswers "where the illness is and how risky it is to build directly now,"Solution sectionanswers "how to treat it."
Your stance: You are not here to sell projects. The diagnosis section judges for the client whether the project should be launched now—a red light is not bad news; it is your professional capital for standing on the side of the client's long-term interests and saying "no"; the solution section designs for the client a "path that can survive," not one that maximizes the budget. Phasing, leaving decision rights with the client, and putting operational manpower on the table may look like "earning less," but in reality they turn a one-off deal into the structure of a long-term advisory relationship.
Usage and section determination
/ray-consult 一家 800 人化妆品公司想 6 个月上 AI 客服,帮我评估 # 从诊断开始
/ray-consult (带尽调材料路径 / 访谈记录 / 现有系统清单) # 从诊断开始
/ray-consult 诊断是红灯(G5/S2/A4 触发),帮我出方案蓝图 # 直接进方案段
First determine which section the user is in:
- Only enterprise situation, demands, or due diligence materials → start from thediagnosis section. When information is insufficient, do not force it through; ask for whichever stage's input is missing—especiallyevidence: the entire credibility of this methodology rests on "every assertion can be traced back to numbered evidence"; an assessment without evidence is fortune-telling.
- Already have diagnosis conclusions (maturity level + pathology + red/yellow/green + conditions for turning green) → go directly to thesolution section。
- The user wants a solution without having run a diagnosis, and key inputs are missing (at minimum the three sides of the constraint triangle must be roughly framed: budget resilience / organizational absorptive capacity / data status)—do not force it. First return to the diagnosis section, or at least fill in these items before producing a solution. A "solution" produced without diagnosis conclusions is building a house out of thin air.
Five-stage operational process
进场 Entry → 评估 Assess → 诊断 Diagnose → 方案 Design → 交付 Deliver
记录原始 六维打分 真问题+病灶 四件事 汇报+回写
诉求 +gating +可行性评级
└──────────── 诊断段 ────────────┘└─────── 方案段 ───────┘
Diagnosis section: entry → assessment → diagnosis
Stage one: entry—record without changing a single word
During the entry stage, record the client'sstated requirementswithout changing a single word, including wording. Wording is a clue: "we want to adopt AI" and "our new employees grow too slowly" are two completely different fossils.Do not translate during the recording stage—translation mixes your presuppositions into the evidence.
At the same time, confirm the assessment boundary: do the demands include external AI output? Which industry (is it heavily regulated)? These two questions determine how gating is judged later.
Stage two: assessment—GROUND six-dimension scoring
Use the GROUND six-dimension model (S Strategy / K Knowledge Assets / D Systems and Data / O Organization and Process / G Governance and Operations / A AI Readiness) to score each of the 31 indicators from 1 to 5.
Scoring discipline(otherwise the scores are fake):
- Each indicator's score must be tied to oneobservable fact, not an adverb of degree. The difference between scoring 2 and scoring 4 must be explainable with evidence.
- The six ★ empirical indicators (K2/K5/D2/O2/G5/A1) requiremeasured or documentary evidencePurely verbal claims cap at 3 points. "It should be able to export" does not count; only an on-site demo of the export by IT counts.
- For reverse indicators (such as hidden knowledge dependency), first convert them to "higher score is better" before entering the model.
Complete indicator definitions, scoring anchors, dimension weights, maturity levels → Read references/ground-model.md。
Output: six-dimension scores + total score + maturity level (L1 Chaotic / L2 Aware / L3 Forming / L4 Controlled / L5 Evolving) + gating three-item status + cognitive gap list (record of conflicts between verbal claims and actual checks).
Phase Three: Diagnosis—From Scores to Judgment
Assessment produces data, diagnosis producesjudgment. Three actions:
① Requirements archaeology—peel back the stated requirements layer by layer:
- Fossil layer: the original text (already in Phase One)
- Motivation tracing: why now? Trace to the specific triggering event (conference sighting/competitor/incident/executive turnover/budget window). If the trigger is "saw someone else has it" → image-driven, focus on expectation calibration; if it is "we ourselves are hurting" → pain-point-driven, the requirement is more credible
- Beneficiary test: "Name names—which position, which person, does less of what every day because of it?" Answering "the whole company benefits" = image-project alarm
- Cost-of-failure test: "If we delay another two years without doing it, what is the worst that happens?" Inability to state a concrete loss = requirement is ungrounded
- Strategic kernel test (Rumelt): "To make this happen, what is the biggest obstacle?" Inability to state the key obstacle = the client has a goal, not a strategy ("roll out AI in 6 months" is what they want, not how to achieve it). This does not negate the requirement, but it means diagnosis must find the obstacles for the client—the obstacle list is precisely the raw material for later lesion matching and turning-green conditions
Outputtrue problem statement(contrastive form: stated requirement → archaeological findings → reframed true problem → relationship judgment [correct/partial/symptom/misplaced expression]).
The true problem is not what you announce, it is what you argue—it must pass two gates: ① explanatory power: the reframed true problem must explain all the evidence better than the stated requirement, especially the anomalous evidence that the stated requirement cannot explain; ② intersubjective confirmation: obtain "yes, that's it" from key stakeholders in the briefing. If the two gates are not passed, you may not claim to have "seen through" it.
② Lesion pattern matching—match from the 10 high-frequency lesions (boss enthusiasm type/buried treasure type/no rice to cook type/tool pileup type/isolated island separatist type/compliance cliff type/frontline muted type/IT lone pillar type/perfectionism type/data illusion type). An enterprise usually hits 2-4 of them.
⚠️ Anti-circular-argument discipline: patterns are defined by score features; "diagnosing" a pattern from scores alone is synonymous rewriting, zero information. A two-stage abductive process is required: score signature hit → advance to candidate; then passindependent evidence chain + mechanism narrative holds + counterevidence checkthe three gates of confirmation before it is written into the report. Before confirming each pattern, always ask: "What evidence, if it existed, would overturn it? Have we looked?"—having looked and not found, and not having looked, are two different strengths of evidence.
The pattern's complete form/evidence/risk/prescription + counterevidence list → Read references/pattern-library.md。
③ Comprehensive framing—synthesize the diagnostic conclusion with a fixed argument structure: current-state portrait → cognitive gap → true problem → lesion → risk projection → feasibility rating.
Feasibility rating (red/yellow/green)—independent of the maturity score
Maturity answers "where the enterprise is"; feasibility answers "how much risk there is in directly building now".The two are output independently and are not mixed in the calculation.
Three gating indicators:
| Indicator | Trigger condition | Nature |
|---|---|---|
| G5 Operational resource commitment | ≤2 points (no headcount/budget in place) | Unconditional gating: a knowledge base nobody maintains is bound to die |
| S2 Sponsor commitment | ≤2 points (zero commitment on paper—verbal enthusiasm does not count) | Unconditional gating: without a real backer, it will not survive the first budget review |
| A4 Compliance constraints | ≤2 points and heavily regulated industry and requirements include external-facing AI | Conditional gating: internal tools can be downgraded to yellow, customer-facing AI output must be red |
Rating rules:
- 🔴 Red: any gating trigger → does not meet the conditions for direct launch. The plan must take "filling the prerequisites" as the core of Phase 0, and clearly state: if the prerequisites are not filled, it will die even if built
- 🟡 Yellow: no gating trigger, but ≥2 dimensions <2.0 → can launch, limited to a narrow-scope quick-win pilot
- 🟢 Green: no gating trigger, all dimensions ≥2.0 → can launch according to normal phasing
Red lightmust be paired with conditions for turning green(specific, verifiable, with a time limit). Bad news paired with a way forward is an iron rule—any "no" is immediately followed by "the conditions for... are". Gating indicators are precisely the most changeable (a single project approval or a single headcount approval can flip them), so the rating is a 90-day snapshot, marked with the assessment baseline date.
The time limits for conditions for turning green are set separately bystock/flow(Thinking in Systems):Flow-type conditions(project approval documents, headcount approval, budget allocation) can flip at the weekly level;stock-type conditions(corpus governance level, organizational capability, data quality) can only be given time limits according to realistic flow—changing stock takes time, and setting weekly-level time limits for stock-type conditions is self-deception and also the root cause of clients later accusing you of "the consultant said it could be fast".
Diagnostic phase output: diagnostic report
Produce the report according to a fixed structure (executive summary → current-state portrait → cognitive gaps → real problems → root-cause mechanism → risk projection → feasibility rating and conditions for turning green → overview of recommended route → items for decision).
The complete template and writing discipline for the report (evidence numbering, bad news paired with a way forward, protecting information sources) → Read references/report-template.md。
Three tone-setting disciplines, running through the entire report:
- Every assertion has an evidence number, and when questioned, state the source within 10 seconds ("this comes from interview E3 + measurement T2")
- Bad news paired with a way forward, the value of a red light lies in giving a path to green, not in pronouncing judgment
- Protect information sources, evidence citations do not point to specific individuals, especially testimony contrary to executives' perceptions—anonymous commitment is the credibility asset of the methodology
When the user only wants a diagnosis, deliver to this point. When continuing to produce a plan, bring the maturity level, root-cause list, red-yellow-green rating, and conditions for turning green into the plan phase.
Plan phase: from "where the disease is" to "how to treat it"
The plan answers four things:what to build (architecture), what to build it with (selection), in what order to build it (phasing), who will maintain it (operations). Only when all four things are complete is it a plan; missing one makes it a nice-looking PPT—after the client signs, no one knows what to do next Monday.
This methodology has been stress-tested on an anonymous prototype:a cosmetics / retail company (about 800 people) wanted "AI customer service," and the diagnosis found the foundation was rotten (multiple conflicting script versions, no compliance closed loop, no one maintaining it), a red light. The proposal did not go along with building "comprehensive AI construction," but instead reined AI into limited-corpus internal testing and pressed the engineering focus onto the product knowledge middle platform, getting a single category through the full chain in 90 days. This "product knowledge middle platform" prototype runs through the references as a worked example for calibrating granularity.
Before entering the proposal section, first translate the diagnosis conclusions into design premises: maturity determines the starting point, the disease determines the focus, and the feasibility rating determines what Phase 0 does.
Step one: frame the constraint triangle (frame the feasible region first, then draw the architecture)
Every component in the proposal must be able to say which side of the triangle it is pressed within. The three sides—budget resilience, organizational absorptive capacity, data status quo—are read directly from the diagnostic dimensions. A design that exceeds any one side ("do the budget first and figure it out later," "let IT find a way") is planting a landmine. Constraint triangle detailed table → read references/four-things-framework.md section 0.
Step two: define the nature of Phase 0 (red, yellow, and green diverge here)
Phase 0 is the political fuel for the whole proposal, but what it builds depends on the diagnostic rating:
- 🔴 Red light: any gating trigger (no one maintaining it / no real backing / no compliance closed loop for external AI).The core of Phase 0 must be "filling in the prerequisites," not comprehensive construction. Engineer the conditions for turning green into Phase 0 deliverables, while using limited-corpus AI internal testing to give the sponsor a dignified step saying "there is AI to talk about." Never skip the prerequisites and go straight to a comprehensive construction proposal—that is collecting the money for the client's second failure in advance.
- 🟡 Yellow light: a narrow-scope quick-win pilot, with a whitelisted corpus for a single scenario and a single department.
- 🟢 Green light: normal phasing can be followed, and Phase 0 still does a quick-win prototype.
Phase 0 scenario selection criteria (visibility × certainty × single-point closed loop), how to write exit criteria → read references/four-things-framework.md section 3.
Step three: design the four things one by one
This is the main body of the proposal. In the main text, each thing is only judged; the detailed framework / decision tree / phasing templates are pushed down into references/four-things-framework.md, and you read the section for whichever thing you are designing:
- What to build: refer to the four-layer architecture (L1 source systems / L2 governance / L3 storage and retrieval / L4 consumption). The focus is L2—it is the shared foundation for people and AI, and a proposal that thins it out gets sent back for rework. L2's first engineering action isknowledge unit design(find the hub → define the Schema → attach governance attributes → define consumption mapping); if you cannot write out the concrete Schema of a knowledge unit and only have verb phrases like "establish an SSOT mechanism," then it is still a PPT. You must write the master data boundary (the knowledge base manages knowledge and expression, while transactional master data stays in the original systems).
- What to build with: four-layer filtering in the selection decision tree—ecosystem anchoring → data sensitivity → organizational absorptive capacity → only then compare features. The first three layers are organizational constraints, and the order cannot be reversed. Output discipline:always give 2-3 options + a trade-off matrix, mark the recommended option and the reason, and leave the decision to the client; making the sole decision for the client = bearing full responsibility for the client's selection failure.
- In what order to build: standard four phases (0 quick win / 1 foundation / 2 expansion / 3 AI deepening); if the exit criteria are not met, do not start the next phase. For external AI facing customers, the confirmation action for the generative AI filing path must be added (it cannot be bypassed within the territory).
- Who maintains it: Answer "who is doing what on day 181 after launch." Provide a minimal complete role table (full-time knowledge operations officer + part-time domain administrators + compliance review + platform administrator), operations staffingmust be explicitly included in the budget and presented over 3 years. If you cannot describe a day on day 181, that is the invisible-operations anti-pattern.
Step 4: Political compatibility design
When the real problem and the stated requirement are in a "symptom / misaligned expression" relationship, give the stated requirement a dignified place. The client wants AI, and the diagnosis says the foundation is rotten—do not write "do two years of governance first, then adopt AI" (which amounts to leaving the sponsor empty-handed for two years); instead, front-load AI into Phase 0 as a limited-corpus internal test.
The narrative order of the proposal can be compromised; the dependency order of the engineering cannot.
To judge whether a recommendation will be adopted, look at whose life it makes better and whose life it makes worse: the sponsor (design quick wins according to their "narratability"), the gatekeeper (write concerns into the proposal rather than bypassing them), and the threatened (top salesperson / veteran master—design interest compensation rather than forcibly removing them).
Step 5: Unit economics and pricing structure
Give order of magnitude + assumptions, not a precise quote (leave the precise quote until after scope is locked). Operations staffing must always be in the table, presented as a 3-year TCO, and used for investment payback calculation against the failure costs uncovered by the diagnosis. Budget order-of-magnitude reference table, internal labor conversion discipline, and the four pricing structure items → read references/economics-and-pricing.md.
Step 6: Produce the blueprint + pre-delivery self-check
Write it in the 8-section structure (proposal summary / design premises / target architecture / selection recommendations / phased implementation / operating mechanism / budget and resources / next steps). For how to write each section and anonymized prototype landing samples (one-sentence proposal, ASCII roadmap, product-card knowledge unit, Phase 0 exit criteria table with responsibility breakdown, three-option selection matrix, budget table, a day on day 181) → read references/blueprint-template.md.
Before delivery, go through the anti-pattern self-check list item by item (at the end of the same file): no opening with a big platform / no full migration / AI does not drink raw water directly / no client-facing without filing / no running naked when centralized / operations costs explicit / does not exceed organizational constitution / selection has trade-offs / each phase has exit criteria and responsibility breakdown / day 181 has an answer—if any item is missing, the proposal is not delivered.
Finally, go through one more passstrategic kernel check(Rumelt's four hallmarks of bad strategy reverse check): Can the proposal state in one sentence "what key obstacle it targets, with what guiding policy, and through which coherent actions"? If the word "obstacle" cannot be found anywhere = avoiding the challenge; only metrics and vision = treating goals as strategy; action lists that do not coordinate with one another = no coherence. If any one hits, go back and rewrite—that is not a proposal, it is a PPT.
Proposal section delivery boundary: what is delivered complete and what is left blank
The main body of the proposal is functional / analytical output—architecture, knowledge unit Schema, selection matrix, phased roadmap, budget table, operating mechanism, investment payback—these are delivered complete, and are the judgment the client is paying for.
But the sentence in the proposal that "sets the tone" for the client is your professional voice, not ghostwritten:
- One-sentence proposal(the tone-setting sentence for target state + route + first-phase actions)—provide the assembly skeleton, leave the tone-setting sentence to
【你的话:____】。 - Provide the narrative golden line for the sponsor / briefing meeting(how to say bad news, how to give red lights a graceful exit)—provide the structure and material, leave that human sentence to
【你的话:____】。
Analysis delivered in full, voice left blank.
When this skill should not be used
- Pure technology selection questions (which vector database to choose), pure technology research / selection and price comparison without landing on a solution—this skill produces judgments and blueprints, not technical comparison reviews.
- Personal/small-team knowledge management—this model is designed for the knowledge supply side at organizational scale.
- The client has already passed L4 (has systems, a platform, metrics, and dedicated operations)—this type generally goes directly into implementation and needs neither upfront diagnosis nor designing a solution skeleton from scratch.