AI CAD often misinterprets instructions because tools lack full project context, cannot see implicit decisions, and will apply literal edits that ripple beyond what you intended. The fix isn’t longer prompts—it’s writing tasks that declare scope, name who has authority for each field, and embed clear stop/continue checks so unsafe edits pause while independent, read‑only outputs still move work forward.
How to clarify an AI CAD prompt before the model is edited
• State intent and deliverable in one sentence.
• Define the exact selection you expect (views, categories, saved selection, or element IDs)—and note that selections and views do not enforce scope or prevent shared‑type effects.
• Identify authority by field for this project (e.g., “equipment names: MEP naming register; sheet numbers: sheet index CSV”), rather than a generic source hierarchy.
• Specify numeric attributes only when you have a verified source; missing dimensions cannot be derived from look‑alike patterns.
• Fix boundaries: what may be edited (host model, specific instance parameters) and what must not change (links, levels/phases/worksets, family types, shared type values without an approved type strategy, Design Option membership, From/To Room fields).
• Embed stop/continue decisions: stop on destructive unknowns and continue with read‑only, report‑only outputs (external exports or an approved test copy—draft views/schedules mutate the model).
• Ask for clarifications in a compact format (one annotated screenshot plus a short question list).
• Package context once: a short screen recording with spoken intent, annotated screenshots, selected Revit/AutoCAD elements, and relevant PDFs/CSVs. With ArchiLabs Desktop you can supply those artifacts and, when approved, have an AI teammate for Revit and AutoCAD create/update native elements and produce documentation; integration availability varies by environment, and there’s no automatic pause, dry‑run, or change‑log guarantee.
For scoping realism and current boundaries, see What AI Can and Can’t Do in Revit Today: A Clear Guide and standardize inputs with the Revit Model Context Protocol.
When should an AI CAD task stop and ask for clarification?
• Missing or ambiguous identifiers
• Stop when an element cannot be uniquely matched (e.g., duplicate “AHU-03” in two phases).
• Continue with a read‑only report listing each ambiguous candidate (element IDs, category, view/sheet references) and an annotated screenshot.
• Scope crossings and shared types
• Stop before an edit implies type changes, edits to links/levels/phases/worksets, or modifying shared type values to affect a few instances.
• Continue with a proposed change list (IDs, fields) and a note on the broader impact; include the approved type strategy if instance‑only edits won’t achieve the goal.
• Renames and print labels
• Stop if a rename could change printed labels (e.g., Title on Sheet) or tag content.
• Continue with a preview table showing current vs proposed values and which tags/title blocks would change.
• Batch tasks from CSV
• Stop when a required view or title block is missing; repeated CSV rows do not validate repeating a view across sheets.
• Continue with a readiness checklist: ready rows, blocked rows, and exact missing resources.
• Proof of change
• Stop short of creating draft views/schedules in the live model.
• Continue with external exports or run in an approved test copy; remember a duplicated view is not a frozen snapshot, schedule exports may omit filters/settings, and row counts do not equal element counts without itemization and filters.
Three AI CAD prompt mistakes and how to fix them
1) Ambiguous equipment identifier
• Weak instruction
• “Rename AHU-03 to AHU-3 across the model to match the register.”
• Why it fails
• Multiple elements may carry “AHU-03” across phases or options; views/selections won’t prevent edits to the wrong instance or to a shared type.
• Improved instruction
• Intent: “Update the approved instance Equipment_ID field to match MEP_NamingRegister.csv for air‑handling units on Level 2, existing phase only; instance parameters only.”
• Selection: saved set ‘L2_AHUs_Existing’ plus attached element ID list.
• Authority by field: “Equipment_ID field is governed by MEP_NamingRegister.csv (column ‘Number’).”
• Boundaries: no edits to family types, Design Options, or linked models; do not modify shared type values.
• Stop/continue: stop if a register name maps to more than one candidate; continue with an external diff (CSV) listing duplicates and screenshots of each location.
• Useful held output
• AHU_Rename_Readiness.csv showing ID, current Equipment_ID, proposed Equipment_ID, and a “Reason” column for conflicts; one annotated plan screenshot per ambiguous case.
2) A blank Title on Sheet changes the printed view title
Weak instruction: “Rename these views using the new browser naming standard, but keep the sheets looking the same.”
The conflict is between View Name and the view's Title on Sheet. When Title on Sheet is blank, the viewport title normally falls back to View Name. This is separate from Sheet Name and the sheet's title-block labels.
A better instruction names the model and view identities, supplies the old-to-new browser names, and requires a preview of each affected viewport's currently displayed title. Preserve explicit title overrides. For a blank override, either obtain approval to set Title on Sheet to the exact previous displayed title or defer that rename. Keep sheet numbers and viewport detail numbers outside this task.
For example, a view named “MEP-PLANT-1” with a blank override prints “MEP-PLANT-1.” Renaming it to “M-PLANT-L01” would change that printed text. An authorized override of “MEP-PLANT-1” preserves the original display; an override of “PLANTROOM PLAN” would be a separate wording change.
The useful held output is a view-rename register showing document/view identity, current and proposed View Name, current Title on Sheet, effective printed title, affected sheets, and any required approval. Review every affected sheet in a small pilot after applying the accepted map.
3) Missing views/title blocks for CSV‑driven sheet creation
• Weak instruction
• “Create all sheets in the CSV and place the listed views.”
• Why it fails
• If a view or the specified title block is missing, creation fails or substitutes the wrong resources; repeating a view name in the CSV doesn’t make repeated placement valid.
• Improved instruction
• Intent: “Create sheets only for rows whose Title Block and all listed views already exist; place each view once.”
• Selection: host model only.
• Authority by field: “Sheet number/name from SheetIndex.csv; title block family from the project library.”
• Boundaries: no view creation; no type substitution; do not place any view more than once.
• Stop/continue: stop on any row with missing resources or duplicate view usage; continue with a readiness checklist and a duplicates report (view name → target sheets).
• Useful held output
• SheetIndex_Readiness.csv with Ready/Blocked flags, MissingTitleBlock, MissingViews, and DuplicateViewUsage columns; one screenshot locating each missing view in the browser (or noting absence).
Independent, approved items (for example, rows marked Ready) may proceed after the dependency review, while blocked lines wait for a decision.
What an AI assistant can do while model decisions are unresolved
• Preflight readiness checks on your packaged context to flag ambiguous IDs, shared‑type risks, missing views/title blocks, and duplicate placements before edits happen.
• Read‑only “continue” outputs while decisions are pending: external diffs, annotated screenshots, and CSV checklists that unblock reviews.
• Bounded edits once greenlit: create/update native elements, place existing views, and update parameters within the declared scope and authority rules.
Rewrite one ambiguous CAD task as a scoped instruction
Take your next ambiguous task, rewrite it using the improved pattern (intent, selection, authority by field, boundaries, stop/continue), attach an annotated screenshot and a short screen recording, and ask for the external preview outputs first; only then approve the bounded edits you actually want.
Understand what Revit AI can do, where model access and source data limit results, and how to review geometry, parameters, and documentation.
Learn about how Model Context Protocol (MCP) is changing the way we use tools like Autodesk Revit and the future of AI agents and architecture