You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Moved from issue #340, originally opened by @luffichen on 2025-11-26. Continuing the conversation here in Discussions — the original issue thread (including any comments) stays available at #340 for the record.
Summary:
The construction documents should be detailed to the extent of "which files to add/modify, how to modify them specifically, and how the key code is implemented," reducing the space for AI's free play.
Issue 1:
Generated documents do not explicitly reference pre-prepared technical solutions (PUML diagrams, data structures, etc.)
Root cause of the issue
The current process may default to treating "technical solution documents in the proposal" as "background input for generating documents", but does not take "external document references" as a necessary part of the generation logic. This results in the final output only extracting content without retaining the address links of the original documents, affecting the completeness of information during subsequent traceability or collaboration.
Solutions
Clearly specify the requirement of "mandatorily referencing document addresses" in the prompt
When submitting a requirement, it is necessary to add the instruction of "explicit reference" in the prompt. For example:
"Generate a document based on the technical solutions in the attached proposal (PUML flow chart address: [your document link 1], data structure definition address: [your document link 2]). It is required to explicitly mark the address of the referenced original document in the corresponding chapter of the document (such as "1.2 Basis for Technical Solutions") to ensure that each technical detail can be traced back to the corresponding solution."
(Note: If the document is a local file, you can add "The original technical solution document has been uploaded as an attachment, and the document must be marked with 'Reference attachment: Chapter X in proposal_2024xx.pdf'")
Reserve a "Reference Documents" module in a fixed chapter of the generated document
If there is a template for the generated document, you can actively request to add a "List of Reference Documents" chapter. For example:
"The end of the generated document must include a '3 Reference Documents' chapter, listing all technical solution documents relied on this time, in the format: '[Serial Number] Document Name - Document Address / Attachment Path - Core Reference Content (e.g., PUML Sequence Diagram: User Login Process)'."
Issue 2
task.md is simplistic, and model implementation does not follow the details in design.md (the relationship between documents is implicit)
Root cause of the issue
The core contradiction is the "unclear responsibility boundary" between task.md and design.md, causing the model to only recognize the "direct task instructions in task.md" without associating "design.md as the detailed constraints for task implementation" — essentially, the binding relationship between "task objectives" and "design specifications" has not been clearly informed to the model.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Note
Moved from issue #340, originally opened by @luffichen on 2025-11-26. Continuing the conversation here in Discussions — the original issue thread (including any comments) stays available at #340 for the record.
Summary:
The construction documents should be detailed to the extent of "which files to add/modify, how to modify them specifically, and how the key code is implemented," reducing the space for AI's free play.
Issue 1:
Generated documents do not explicitly reference pre-prepared technical solutions (PUML diagrams, data structures, etc.)
Root cause of the issue
The current process may default to treating "technical solution documents in the proposal" as "background input for generating documents", but does not take "external document references" as a necessary part of the generation logic. This results in the final output only extracting content without retaining the address links of the original documents, affecting the completeness of information during subsequent traceability or collaboration.
Solutions
Clearly specify the requirement of "mandatorily referencing document addresses" in the prompt
When submitting a requirement, it is necessary to add the instruction of "explicit reference" in the prompt. For example:
"Generate a document based on the technical solutions in the attached proposal (PUML flow chart address: [your document link 1], data structure definition address: [your document link 2]). It is required to explicitly mark the address of the referenced original document in the corresponding chapter of the document (such as "1.2 Basis for Technical Solutions") to ensure that each technical detail can be traced back to the corresponding solution."
(Note: If the document is a local file, you can add "The original technical solution document has been uploaded as an attachment, and the document must be marked with 'Reference attachment: Chapter X in proposal_2024xx.pdf'")
Reserve a "Reference Documents" module in a fixed chapter of the generated document
If there is a template for the generated document, you can actively request to add a "List of Reference Documents" chapter. For example:
"The end of the generated document must include a '3 Reference Documents' chapter, listing all technical solution documents relied on this time, in the format: '[Serial Number] Document Name - Document Address / Attachment Path - Core Reference Content (e.g., PUML Sequence Diagram: User Login Process)'."
Issue 2
task.md is simplistic, and model implementation does not follow the details in design.md (the relationship between documents is implicit)
Root cause of the issue
The core contradiction is the "unclear responsibility boundary" between task.md and design.md, causing the model to only recognize the "direct task instructions in task.md" without associating "design.md as the detailed constraints for task implementation" — essentially, the binding relationship between "task objectives" and "design specifications" has not been clearly informed to the model.
All reactions