Simulink Code Detailed Design Md 2.0

Simulink Code Detailed Design Md 2.0

Purpose

Generate a reusable, evidence-grounded Chinese detailed-design Markdown document for folders that contain generated C source code and Simulink or Stateflow screenshots. Treat the output as a design handoff document and a learner-facing algorithm note: explain the complete calculation chains, module hierarchy, formulas, gating conditions, filters, saturations, outputs, downstream destinations, and the control-design reason behind important choices so another engineer can understand the subsystem without opening every file.

Preserve the style of the golden example in references/golden-example.md: chain-oriented structure, engineering prose, formulas with explanation, Mermaid diagrams per major chain, screenshots placed near the supported content, and explicit uncertainty labels. For requests that mention "同风格", "复刻", "照这一版", or "同等级别", load references/golden-replication-contract.md before drafting and treat it as the output-shape contract.

For golden-style work, also load references/paper-chain-writing-contract.md. This file captures the most important writing idea from the approved document: formulas are not independent facts. They form a numbered derivation from chain inputs to a named final output, and the prose must explain how formula (n) feeds formula (n+1).

The document must not stop at "what the code calculates". For each important formula group, explain what control problem the code is solving, why the limiter/filter/reset/feedback term exists, what failure mode it prevents, and what downstream behavior changes because of it. If the source comments do not state the design intent, write the interpretation as 根据源码结构和上下游关系推断 instead of presenting it as fact.

DTC/DTF examples in this skill are validation examples, not a domain constraint. When the analyzed folder is about another controller or subsystem, adapt the wording to that subsystem's real signals, actuators, states, and safety boundaries. Do not introduce DTC-specific meanings unless the local code or screenshots actually contain them.

For chassis-dynamics folders, add a vehicle-dynamics interpretation layer. Explain how the code uses wheel speed, axle speed, reference speed, slip, longitudinal/lateral acceleration, yaw or steering-related quantities, brake/drive torque, road friction indicators, ABS/VDC/TCS states, drivetrain configuration, and release gates to protect vehicle stability, traction, braking behavior, drivability, and actuator limits. This is broader than PID. PID, PI, feedforward, limiters, state machines, hysteresis, observers, filters, counters, release logic, lookup tables, arbitration, fallback paths, and plausibility checks are all algorithm-design material.

Required Fusion Skills

Treat these two skills as mandatory fused behavior, not optional inspiration:

• •Humanizer Zh: read the installed humanizer-zh/SKILL.md when drafting or reviewing the Markdown. Apply its useful parts to technical prose: remove filler, inflated conclusions, vague attribution, forced three-part phrasing, decorative transitions, and chatty assistant language. Keep concrete engineering statements, source-backed uncertainty, and direct Chinese explanations.
• •Simulink Image Stitching: read the installed simulink-image-stitching/SKILL.md when screenshots are split, partial, overlapping, or tiled. Use its script and verification rules before referencing those screenshots in the Markdown. Final output should reference the accepted stitched image, not an unverified pile of partial images.

Use the two fused skills during self-review as well: inspect whether the prose still sounds mechanical and whether every partial screenshot was stitched or explicitly justified. For Humanizer Zh, the goal is not casual writing; the goal is readable engineering Chinese. Formula explanations should sound like one engineer walking another engineer through the calculation chain: what this value comes from, why this comparison is made, where the result goes next, and what downstream behavior changes.

Encoding Guard

All skill files, generated Markdown files, and validation scripts are UTF-8 text. On Windows PowerShell, always read them with explicit UTF-8 commands such as Get-Content -Encoding UTF8 or Python Path.read_text(encoding="utf-8"). Do not conclude that Chinese headings are corrupted just because Get-Content without -Encoding UTF8 displays unreadable mojibake. Re-read the same file as UTF-8 before editing.

When writing the output Markdown, keep real Chinese headings and prose in UTF-8. Do not copy garbled text from terminal output back into the document. Before delivery, scan the Markdown for replacement characters and common mojibake fragments; any real mojibake in the file is a blocker.

Core Workflow

1. Establish scope

- Use the project folder root requested by the user; otherwise use the current workspace folder. - Name the output <project-folder-name>详细设计说明.md unless the user requests another file name. - Read existing good documents in the folder first when present, especially files named *详细设计说明*.md, and reuse the approved structure and tone. - When the user asks to reproduce this exact approved style, read references/golden-replication-contract.md and references/golden-example.md before choosing headings, section order, diagram density, and formula explanation depth.

1. Inventory all evidence

- Enumerate every source file recursively before analysis. Include at least .c, .h, .cpp, .hpp, .m, .tlc, .arxml, .slx metadata when available, and project-specific text/config files that affect generated logic. - Enumerate every screenshot or model image recursively. Include .png, .jpg, .jpeg, .bmp, .tif, .tiff, and .gif. - Record counts in the document, for example "原始 C 文件：97 个；Simulink 截图：79 张". Do not analyze only representative files.

1. Process Simulink screenshots

- Inspect all screenshots as structural evidence for subsystem hierarchy, signal adjacency, bus routing, and module placement. - Inspect Simulink Goto and From blocks as signal-flow evidence. Build an internal Goto/From tag map before drafting: tag name, producer block or source subsystem, consumer block(s) or target subsystem(s), visible hierarchy/scope, supporting screenshot path, and inferred signal role. Use this map to decide subsystem dependencies and signal direction; do not turn it into a standalone output table by default. - Treat a Goto tag and From tag with the same name in the same valid Simulink scope as the same signal, even when no visible line connects them. Use this to reconstruct cross-subsystem inputs, outputs, fan-out, and downstream destinations. - Respect Simulink tag visibility. If a Goto Tag Visibility block, local/scoped/global marking, enclosing subsystem, or screenshot context shows scope, use it. If scope cannot be proven from screenshots, write 根据截图中同名 Goto/From 标记和可见层级推断 and avoid connecting same-name tags across unrelated hierarchy levels as fact. - When a tag has one Goto and multiple From blocks, treat it as fan-out from one producer to multiple consumers. When a From has no visible matching Goto, or a Goto has no visible consumer in the available screenshots, keep it as unresolved screenshot evidence rather than inventing a source or destination. - For incomplete, split, overlapping, or tiled screenshots, load the installed simulink-image-stitching/SKILL.md and apply the Simulink Image Stitching method before using the image in the document. Use its bundled scripts/stitch_simulink_screenshots.py when available, then visually verify seams. - Insert screenshots near the exact subsection they support. Do not collect images at the end. - Verify every Markdown image path exists before delivery.

1. Analyze all source code

- Build notes per file and per function before drafting. - Extract inports, outports, terminal assignments, calibration parameters, constants, formulas, branches, reset logic, previous-cycle state, timers, counters, filters, limiters, validity flags, release flags, and diagnostic facts. - Build a code input/output signal inventory before drafting: collect .Inport() declarations, explicit Outport declarations when present, final externally visible assignments, state-machine outputs, and signals consumed by other child modules. Classify each signal by role and translate the signal name into Chinese. - Trace current-cycle signal flow separately from feedback and previous-cycle references. Include both visible Simulink lines and virtual Goto/From links when reconstructing signal flow. - Treat final assignments as the source of truth when earlier code computes values that are later overwritten.

1. Build chain-oriented design

- Organize the main body by complete calculation chains rather than by file order. - Immediately after ## 1. 模块定位, add ### 1.1 代码输入与输出信号表. Use categorized tables for code inputs and outputs. Each row must include signal name, direction, category, Chinese translation, actual meaning/use in the control chain, and source evidence or downstream destination. - For each chain, include: objective, inputs, intermediate variables, conditions, limiters, filters, formulas, outputs, and downstream destinations. - Start every major chain with an endpoint paragraph: <链路名>的终点是 <final_output>。链路先...再...最后... Name the intermediate quantities that carry the chain. - Build an internal formula ledger before drafting: formula number, purpose, inputs, output, and which later formula or branch uses that result. Do not use machine-translated wording such as "消费公式" in the final prose. - Build an internal design-intent ledger before drafting: source fact, likely control-design purpose, protected failure mode, affected downstream behavior, and confidence level. Use source comments as evidence when available; otherwise label the item 根据源码结构和上下游关系推断. - For every major calculation chain, include a short 设计意图与控制思想 subsection or paragraph near the formulas. This subsection must answer the learner's questions: why this chain exists, why the code chooses these thresholds/filters/limiters/state gates/arbitration rules, what would go wrong without them, and how the final output changes the controller or vehicle behavior. - For chassis-dynamics chains, explicitly connect software quantities to vehicle behavior: wheel lock or wheel spin tendency, driven versus non-driven axle behavior, low-mue or split-mue sensitivity, ABS/VDC/TCS coordination, braking versus coasting versus propulsion, reference-speed trust, lateral acceleration effects, rough-road or aquaplaning suppression, axle split/AWD/FWD/RWD allocation, and the trade-off between intervention strength and driver comfort. - Place a Mermaid flowchart near the start of every major calculation-chain section. Use multiple readable diagrams instead of one overloaded diagram. - In ## 3. 子模块依赖与信号流向, use the internal Goto/From map as evidence when deciding which subsystem produces a signal, which subsystem consumes it, and whether the relationship is direct, fan-out, or inferred across hierarchy. Write the final section as subsystem dependency and signal-flow prose/diagrams; do not default to listing Goto/From tags or adding a separate tag table. - In Mermaid diagrams, represent important Goto/From-derived connections as normal signal edges using the signal's physical or software meaning. Mention Goto/From:<tag> only when the tag itself is necessary to justify an otherwise non-obvious cross-subsystem connection or to mark an unresolved/inferred relationship. - Include a "主要子模块功能说明" section that explains each major child module by function定位, 输入信号, 输出信号, 检测/计算条件, 满足条件后的反应, and dependencies.

1. Write evidence-grounded formulas

- Convert real formula content from screenshots and code into Markdown/LaTeX formulas. Do not paste formula screenshots as the only explanation. - Expand fixed parameter expressions when screenshot or code evidence exposes their structure; do not leave only P_xxx names when the formula can be recovered. - Number every displayed formula with \tag{n} or \tag{na}. Do not leave unnumbered displayed formulas in golden-style output. - Write important formulas as centered display formulas with \[...\] or fenced math code blocks. Do not use inline math, Markdown tables, screenshots, or code blocks as the only representation of a main equation. - Give every independent equation or inequality its own formula number. If one display block contains two separate equations or inequalities, each relation needs its own \tag{...}; otherwise split them into separate display blocks. Use sub-tags such as 20a and 20b for closely related side conditions. - Keep the same equation or inequality on one visual line at normal formula size whenever it fits. Only wrap it when the line would become too wide; then use aligned continuation lines for the same relation and keep one formula number for that one relation. - Formula renderability is mandatory. Before delivery, check every display formula for balanced \[...\], matched braces, matched \begin{...} / \end{...}, matched \left / \right, and no Markdown backticks or raw code operators inside math. Any formula that could trigger a Markdown or math ParseError is a blocker. - Formula symbols in prose must render as math, too. Write variables with subscripts, superscripts, Greek letters, or LaTeX commands as inline math, for example \(M_{\mathrm{time}}\), \(M_{\mathrm{grad}}\), and \(\Delta v_{\mathrm{rel}}\). Do not wrap these symbols in Markdown backticks and do not leave raw strings such as M_{\mathrm{time}} in normal prose; that makes the subscript display as literal text. Keep source-code identifiers in backticks, for example M_time or DTC_MProp_Limit_Cust.

- After each important formula, write 式中, 逻辑, 设计解读, and 对应源码片段（来源：...）：. - Treat 设计解读 as mandatory for non-trivial control formulas and logic, including but not limited to feedback-controller terms, state-machine thresholds, hysteresis, timers, counters, saturations, filters, anti-windup paths, maximum/minimum torque or speed limits, reset branches, previous-cycle feedback, arbitration, release gates, plausibility checks, fallback references, lookup-table shaping, and mode-dependent signal allocation. The explanation must say why the design exists, not just what code line executes. - For chassis-dynamics code, 设计解读 must use the right physical language when evidence allows: wheel slip, wheel lock, wheel recovery, reference-speed sneakdown, low friction, split friction, axle oscillation, rough road, aquaplaning, braking stability, propulsion request, engine drag, regenerative braking, driver torque request, brake pressure interaction, ABS/VDC/TCS coordination, and driven-axle configuration. Do not reduce these ideas to generic "stability" or "robustness". - In 设计解读, explain the engineering trade-off in plain Chinese: stability versus response speed, comfort versus intervention strength, actuator protection versus control authority, release sensitivity versus false activation, or estimator trust versus fallback safety. Keep it concrete and tied to the actual signal. Do not write empty praise such as "体现了稳健设计" or "增强了鲁棒性". - When explaining reference speed or estimator fusion, state why one source is trusted in one condition and distrusted in another. For chassis dynamics, this often means ABS reference is more meaningful in braking, VDC reference may be better outside braking, wheel-speed references can be dragged down by locked or slipping wheels, and non-driven axle speed can provide a fallback only when the drivetrain configuration makes it meaningful. - When explaining wheel or axle allocation, state why the code chooses minimum wheel speed, average axle speed, slowest-two-wheel speed, driven axle, non-driven axle, or AWD aggregation. Tie the choice to the physical behavior being detected: one wheel in deep slip, an axle losing stability, all driven wheels slowing together, or a non-driven axle acting as a vehicle-speed witness. - When explaining state machines and release gates, state the vehicle-dynamics reason for allowing, delaying, suppressing, or exiting control. Examples include avoiding false intervention at low speed, not fighting ABS/VDC, avoiding torque requests during brake faults, suppressing control on rough road or aquaplaning, or keeping a post-control ramp so wheel recovery does not turn into a torque step. - When a limiter affects a later integrator or feedback path, explain the control-algorithm idea explicitly. Example: if a target command is clipped by a maximum limit and a LimitApplied flag forces the next I-step to decrease, state that this is an integrator windup prevention pattern: once the actuator, plant, or safety envelope prevents the requested command from being applied, the controller stops accumulating a larger hidden I term that would cause overshoot or delayed recovery when the limit is released. - When explaining a module-specific maximum or minimum limit, state the protected boundary. The code is not only "taking min" or "taking max"; it caps a target torque, pressure, current, speed, angle, force, acceleration, duty cycle, state permission, or diagnostic counter so the module cannot demand more than the actuator, plant, customer calibration, fault condition, or time-based safety envelope currently allows. If the exact reason comes only from comments or naming, cite that evidence or label it as inference. - When explaining filters, counters, or hysteresis, state what jitter or false transition they prevent. A PT1 filter should be described as making an input move gradually before it is used by a release or target-torque decision; a counter/timer should be described as retaining or delaying a condition across cycles, not merely as "计时". - A formula block is incomplete if a learner can read the formula and source snippet but still cannot answer "why was this algorithm designed this way?" Add the missing 设计解读 before moving on. - Treat 式中 as a mandatory variable-meaning contract, not a code-variable dictionary. For every symbol, use this shape: \(symbol\) 为/表示 <中文物理或控制含义>，对应 <source-code variable / screenshot signal>; include unit when inferable and chain role when helpful. The Chinese meaning must appear before or beside the source mapping. - In 式中, explain every variable or symbolic label that appears in the formula. Each explanation must include both the source-code/screenshot mapping and a Chinese physical/control meaning, with unit when inferable. This includes short local symbols, branch labels, Boolean flags, calibration aliases, constants, intermediate min/max values, axis/wheel suffixes when they carry meaning, and previous-cycle symbols such as k-1. Do not write only "x 对应 sourceVar", and do not omit a symbol because it looks obvious. - The Chinese meaning must be semantic, not a surface translation of the variable name. Avoid weak explanations such as 为稳定性阈值, 为控制标志, 为补偿系数, 为模式状态, 为偏移量, or 为输出结果 unless the same item also says what signal, condition, state transition, limiter, filter, timer, or downstream decision it affects. - For each symbol, prefer this review question: "If the reader hides the code variable name, can they still tell what the quantity does?" If not, rewrite the explanation. - For formula blocks with more than three symbols, prefer one bullet per symbol or one clearly separated clause per symbol. Do not use 等, 分别对应, or a shared mapping list when that hides a symbol's own Chinese meaning. - Boolean or suitability symbols must explain their true/false meaning, not only the function name. Example: write \(Q_{FL}\) 为前左轮轮速质量适合 ABS 控制的布尔结果，对应源码判断 Signal_is.SuitableForAbsControl(WSS_Quality_FL). Do not write only \(Q_x\) 对应 Signal_is.SuitableForAbsControl(WSS_Quality_*). - Threshold, limit, offset, and margin symbols require a stronger explanation. The 式中 item must answer: which signal is compared or limited, which side/direction matters, what state/permission/action changes after crossing the boundary, and which source variable or calibration it maps to. A phrase like 表示不稳定趋势阈值 is incomplete because it does not say what crosses the threshold or what happens afterward. - A threshold explanation is still incomplete if it only names the state pair, such as 表示从 Passive 进入 NoTrq 的不稳定趋势阈值. It must also say the runtime condition and result, for example which speed is lower than the threshold, and whether InstableTendency, release permission, DTC/DTF state, or another downstream flag changes. - Do not compress multiple formula symbols into a wildcard explanation when those symbols appear separately in the formula. Bad: \(Q_x\) 对应 Signal_is.SuitableForAbsControl(WSS_Quality_*). Good: explain \(Q_{FL}\), \(Q_{FR}\), \(Q_{RL}\), and \(Q_{RR}\) as the front-left/front-right/rear-left/rear-right wheel-speed quality suitability Boolean results, then state that all four must be true for RelVehWSSQuality to become true. - Do not write \(v_{\mathrm{abort}}\) 和 \(v_{\mathrm{start}}\) 分别对应 ... without explaining their gates. \(v_{\mathrm{abort}}\) must say that DTC_vRef below the abort speed revokes vehicle-level release; \(v_{\mathrm{start}}\) must say that DTC_vRef above the start speed, or previous-cycle DTCAct_K1, allows the start-speed release gate to remain true. - Offset and margin symbols must explain the inequality they modify. Bad: \(\Delta v_{\mathrm{rel}}\) 对应 DTC_Release_dvOffs_vMin12DTAbovevRef. Good: \(\Delta v_{\mathrm{rel}}\) 为发动机级释放中允许 vMin12DT 高于 DTC_vRef 的偏移裕量，对应该标定；源码判断 vMin12DT < DTC_vRef + DTC_Release_dvOffs_vMin12DTAbovevRef，对应公式中的 \(v_{\min12,\mathrm{DT}} < v_{\mathrm{Ref}} + \Delta v_{\mathrm{rel}}\)，用于判断传动路径速度关系是否仍可接受。 - For state-machine thresholds, name the state transition, release gate, or diagnostic decision that the threshold controls. Use the local domain terms. DTC examples: \(v_{\mathrm{IT}}\) 为 Passive 进入 NoTrq 的不稳定趋势轮速阈值，对应 vThreshInstabTend；当 vMin12DT 或单轮最小速度低于该阈值且释放条件有效时，InstableTendency 置真。\(v_{\mathrm{abort}}\) 为车辆级释放的最低退出车速门限，对应 DTC_Release_vMinAbort；DTC_vRef 低于该门限时车辆级释放被撤销。 \(\Delta v_{\mathrm{rel}}\) 为发动机级释放允许驱动轮速度高于参考车速的偏移裕量，对应 DTC_Release_dvOffs_vMin12DTAbovevRef；它参与源码判断 vMin12DT < DTC_vRef + DTC_Release_dvOffs_vMin12DTAbovevRef 的传动路径可控性判断。 - Use the accepted pattern from the acceleration chain: \(a_{\mathrm{Veh},x}\) 对应 a_Veh_x，表示车辆纵向加速度；\(a_{y,\mathrm{abs}}\) 对应 aVehy_abs，表示横向加速度绝对值；\(C_{\mathrm{err}}\) 对应 DTC_aVehxy_ErrorCorrection，是误差修正速度的标定系数；\(a_{\mathrm{Vehxy},k}\) 对应 aVehxy，是后续低附着、阈值和 DTF 预控制使用的合成加速度。 This is good because a reader can hide the code names and still understand what each quantity is and where it is consumed. - Reject grouped bare mappings such as \(T_{\mathrm{PTC}}\) 和 \(T_{\mathrm{VDC}}\) 对应 Timer_LowMueAfterPTCAct、Timer_LowMueAfterVDCAct. Rewrite as two explicit meanings, for example \(T_{\mathrm{PTC}}\) 为 PTC 激活后低附着保持计时，对应 Timer_LowMueAfterPTCAct；\(T_{\mathrm{VDC}}\) 为 VDC 激活后低附着保持计时，对应 Timer_LowMueAfterVDCAct. If LowMueConfirmed appears in the formula, also explain it as a low-mue confirmation flag, not only name it. - Before leaving a formula block, perform a symbol checklist: every symbol in the displayed formula has one nearby 式中 explanation; every explanation has at least one Chinese meaning phrase (为, 表示, 即, 用于, 作为, etc.) and at least one evidence mapping phrase (对应, 来源于, 映射到, 来自截图, etc.). Missing either piece is a blocker. - Before leaving any formula block, perform a semantic-strength checklist: remove explanations that only state a category (阈值, 门限, 标志, 系数, 状态, 模式, 偏移量, 限值, 输入, 输出, 结果) without a concrete chain role. Add the affected signal, condition, comparison, state transition, timer behavior, limiter target, or downstream consumer. - Before leaving a threshold formula block, perform a threshold checklist: every item containing 阈值, 门限, 上限, 下限, 限值, 偏移, or 裕量 must state its comparison/limiting target and the resulting control action. If the item only translates the variable name, rewrite it. - Keep normal text inside formulas at one visual size. Use one consistent LaTeX text style for branch/mode labels in the same formula block, such as \text{...} or \mathrm{...}, and do not mix \small, \scriptsize, \tiny, \large, \scriptstyle, or ad-hoc Markdown/HTML sizing inside formulas. If branch labels such as FWD/RWD/AWD make the formula cramped or uneven, move the labels and conditions to a table and keep the displayed formula symbolic. - The 逻辑： paragraph must connect formulas in natural engineering Chinese. Write how formula (4) 的结果进入公式 (5)，or how formula (17) determines the filter type used by formula (18). Avoid stiff literal translations such as "公式（5）消费公式（4）", "该链路消费输入", or "该公式驱动后续逻辑". A good paragraph should let the reader follow the calculation without mentally translating code: first name the previous result, then state the current operation, then say which gate, limiter, filter, state transition, or output receives the result. - Keep 逻辑 and 设计解读 separate. 逻辑 explains the data path from one formula or branch to the next. 设计解读 explains the design reason, control intuition, safety boundary, comfort trade-off, or anti-oscillation/anti-windup behavior behind that data path. - Source evidence must include actual fenced c code snippets copied from the source file. Do not only name the file. - For multi-branch logic, imitate the golden example's readable math layout: use short local symbols in formulas, map long calibration names in 式中, split oversized formulas, or use condition tables. Do not create wide display formulas that shrink or look cramped in Markdown. - Do not place more than two displayed formulas in a row without a nearby 式中 and 逻辑 explanation. Test cases such as Fun_DTC showed that grouped formulas can pass visually but fail golden-style density; revise until --strict-golden-shape passes. - Label unsupported interpretation as 根据命名和上下游关系推断.

1. Humanize the engineering prose

- Load the installed humanizer-zh/SKILL.md for the final prose pass. - Write in direct Chinese engineering style. Prefer concrete signal meaning and observed behavior over decorative summaries. - Remove AI-like filler, exaggerated claims, vague attribution, generic transitions, forced three-part lists, empty conclusions, and literal machine wording. - Formula explanation must be natural and continuous. Do not turn 式中, 逻辑, or 设计解读 into a mechanical variable dictionary. Explain the calculation chain in the order the signal actually travels: input or previous-cycle value, current computation, branch condition, limiter/filter/state update, final handoff. Then explain the control idea in human terms: why this shape of calculation is used and what behavior it is trying to avoid or encourage. - Use sentence rhythm like a design review note. Short sentences are fine when the fact is simple; longer sentences are acceptable when they carry a real dependency. Avoid repeating the same sentence frame for every formula. - Ban robot-like technical phrasing in the generated document. Examples: "消费公式", "消费输入", "驱动后续逻辑", "赋能", "体现了稳健设计", "关键作用", "完整闭环", "值得注意的是", "从整体来看", "此外" when it only connects paragraphs, "该模块通过...实现了..." when a direct verb is clearer. - Prefer plain alternatives: "公式（5）使用公式（4）的结果", "该结果进入下一步限幅", "这个偏差随后用于计算目标扭矩", "源码最后把该量清零", "该分支只在制动时改写阈值". - Prefer learner-friendly but still technical explanations. Good: "这里限制最大目标命令，是因为后面的执行器并不能无限跟随目标。目标一旦被上限截住，继续累加 I 项只会把控制器内部推得更高；限制解除时，这个积累量会变成一次过大的请求。" Bad: "该限幅保证系统稳定，体现了鲁棒控制思想。" - State uncertainty plainly. Avoid turning guesses into facts.

1. Validate before delivery

- Before running the script, split draft review by the failure taxonomy in references/paper-chain-writing-contract.md: chain endpoint, derivation continuity, source display, formula display, local-screenshot use, source coverage, abnormal facts, and Humanizer Zh style. - Run scripts/validate_design_md.py <output-md> --project-root <project-folder> from this skill when possible. - Add --strict-golden-shape when the requested output should replicate the golden document's format, content density, and form. - Treat mojibake as a blocker only when it exists in the actual UTF-8 file content. If a terminal view looks garbled, re-read the same file with UTF-8 before editing. - Treat Markdown or formula render failures as blockers. If the validator reports unbalanced formula delimiters, mismatched LaTeX environments, unmatched braces, unmatched \left / \right, or Markdown syntax inside a formula block, fix the formula before delivery. - In strict mode with --project-root, the validator checks that 对应源码片段（来源：...）： fenced c snippets can be found in the local source files after whitespace normalization. Treat mismatches as blockers. - In strict mode with --project-root, the validator checks that the ### 1.1 代码输入与输出信号表 section exists, contains both input and output rows, and mentions all .Inport() signals found in source files. - In strict mode, the validator checks that 式中 mappings are not bare code-variable mappings. Treat any "对应 var" explanation without Chinese meaning as a blocker, even when the source mapping is correct. - Check manually that every source file is represented, every major chain has a Mermaid diagram, image paths exist, formulas are numbered and explained, formulas render without ParseError, real fenced source snippets are shown, every formula variable has a Chinese meaning plus source mapping, and inferred claims are labeled. - If screenshots contain Goto/From blocks, check manually that important same-tag relationships were used as evidence in the signal-flow analysis. Only unresolved tag relationships that materially affect subsystem input/output interpretation need to appear as uncertainty notes. Missing a visible Goto/From relationship that changes subsystem input/output interpretation is a blocker.

Mandatory Output Structure

Follow references/design-md-template.md unless the user provides a stricter template. Keep these sections unless clearly irrelevant:

• •0. 公式符号与排版约定
• •1. 模块定位
• •1.1 代码输入与输出信号表
• •2. 原代码覆盖范围
• •3. 子模块依赖与信号流向
• •3.1 主要子模块功能说明
• •One section per major calculation chain
• •当前源码中的异常事实 when overwrite behavior, dead logic, constant outputs, or contradictory logic is found
• •原代码文件清单
• •设计结论

For golden-style replication, preserve the exact document grammar described in references/golden-replication-contract.md: numbered ## top sections, ### substeps inside chain sections, top-level dependency section before chain sections, chain sections before abnormal facts, and final source-file inventory plus factual conclusions.

Formula And Diagram Rules

Apply references/format-style-rules.md for exact formula, Mermaid, table, and wording constraints. Enforce these minimum rules:

• •Put symbol conventions at the beginning.
• •Avoid ambiguous comma subscripts: write v_{\mathrm{Bez}}^{a} instead of v_{\mathrm{Bez},a}, and v_{\max}^{(2)} instead of v_{\max,2}.
• •Use cases or condition columns for conditional formulas. Do not append raw logic such as !Skip after a formula.
• •Use !Condition consistently for negation in prose and condition tables.
• •Use fractions for division; avoid negative-power notation for ordinary formulas.
• •In prose, keep mathematical symbols as inline math when they contain LaTeX notation or visual structure: \(M_{\mathrm{time}}\) is correct; ` M_{\mathrm{time}} and raw M_{\mathrm{time}} are wrong. Backticks are only for source-code identifiers such as M_time`.
• •Keep Mermaid node labels readable; prefer physical role plus variable name for important signals.

Evidence Priority

Apply references/evidence-rules.md:

1. Final source-code assignments and branch outcomes.
2. Source-code formulas, constants, calibration usage, and state updates.
3. Simulink screenshot topology, signal labels, and same-scope Goto/From tag relationships.
4. Existing approved design documents in the same folder.
5. Naming and upstream/downstream inference, explicitly labeled.

When code and screenshot evidence conflict, describe the conflict and prefer code for behavior, screenshots for structure.

Additional Resources

• •references/design-md-template.md - Complete Markdown skeleton and per-chain section pattern.
• •references/evidence-rules.md - Source/screenshot/inference priority, annotation rules, and coverage expectations.
• •references/simulink-stitching-rules.md - Screenshot grouping, stitching, verification, and insertion rules.
• •references/format-style-rules.md - Formula notation, Mermaid diagrams, tables, prose tone, and prohibited patterns.
• •references/paper-chain-writing-contract.md - Paper-like chain derivation rules: endpoint paragraph, formula ledger, formula numbering, source snippets, and formula-to-formula prose.
• •references/golden-replication-contract.md - Exact section grammar, density targets, and strict self-check rules for reproducing the approved detailed-design Markdown.
• •references/golden-example.md - Approved example document to imitate for structure and depth.
• •scripts/validate_design_md.py - Lightweight final Markdown checker for section presence, Mermaid fences, image paths, and source-file coverage hints.
• •scripts/smoke_test_formula_meanings.py - Smoke test that verifies strict validation rejects bare formula-variable mappings and vague threshold explanations while accepting a concrete formula explanation sample.